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PREFACE 


Management  Consulting  &  Research,  Inc.  ( MCR )  has  been  tasked 
by  the  Office  of  Naval  Research  (ONR)  under  Contract  N00014-81- 
C-0764,  to  develop  techniques  for  shortening  the  weapon  system 
acquisition  cycle  by  the  use  of  concurrency. 

MCR  has  proposed  a  two-phase  study  for  performing  this 
analysis.  The  Phase  I  effort  has  concentrated  on  developing 
guidelines  for  the  Program  Manager  (PM)  to: 

•  identify  and  select  program  activities  amenable  to 
concurrent  scheduling,  and 

•  generate  checklists  that  can  be  used  in  evaluating 

the  cost  and  schedule  risks  associated  with  concurrency 
decisions. 

This  technical  report  documents  MCR ' s  Phase  I  efforts  in  the 
area  of  research  on  concurrency. 

MCR  would  like  to  express  our  appreciation  to  the  various 
technical  groups  and  individuals  who  have  provided  assistance  in 
this  research. 


1 


TABLE  OF  CONTENTS 


SECTION  PAGE 

PREFACE  .  i 

I.  INTRODUCTION . 1-1 

A.  Background . 1-1 

B.  Approach . 1-5 

II.  SUMMARY  OF  BACKGROUND  RESEARCH  .  II-l 

A.  Approach  to  Background  Research . II-l 

B.  Summary  of  Research  Findings  .  II-l 

1.  Definition  of  Concurrency . II-2 


2.  Documentation  Relating  to  Concurrency.  II-3 

3.  Previously  Suggested  Alternatives 


to  Reduce  Acquisition  Time . II-4 

4.  Pros  and  Cons  of  Concurrency . II-5 

5.  Official  Directives  and  Guidance  .  .  .  II-6 

6.  PM  Concurrency-Related  Needs  .  II-8 

III.  OVERVIEW  OF  RISK  ANALYSIS  TOOLS  AND  TECHNIQUES  III-l 

A.  Components  of  Risk  Analysis . III-l 


B.  Available  Analytical  Tools  and  Techniques.  III-2 

IV.  DESCRIPTION  OF  MCR  CONCURRENCY  ANALYSIS  MODEL.  IV-1 


A.  Project  Schedule  Components  .  IV-1 

B.  Overview  of  the  Model . IV-4 


C.  Description  of  Analytical  Process . IV-8 

1.  Step  1:  Construct  Baseline  Schedule  .  IV-10 

2.  Step  2:  Evaluate  Funding  and  Schedule 

Constraints . IV-11 

3.  Step  3:  Determine  Motivation  for  Con¬ 

currency:  Schedule  Protec¬ 
tion  or  Schedule  Compression.  IV-13 

ii 


TABLE  OF  CONTENTS  (Cont'd) 


SECTION 


V. 


VI. 


PAGE 

4.  Step  4:  Determine  Degree  of  Accept¬ 

able  Cost  Risk/Schedule 

Risk . IV- 14 

5.  Step  5:  Develop  Alternative  Schedules  IV-16 


6.  Step  6:  Evaluate  Risk  for  Each 

Alternative . IV-17 

7.  Step  7:  Select  New  Schedule . IV-19 

DISCUSSION  OF  POTENTIAL  APPLICATIONS  .  V-l 

A.  Planning  Needs  and  Considerations . V-l 

1.  Organization  of  the  Project  Management 

Office . V-3 

2.  Project  Activities  and  Events  to  be 

Scheduled . V-10 

3.  Distribution  of  Project  Design 

Responsibilities  .  V-16 

B.  Application  Considerations  .  V-17 

CONCLUSIONS  AND  RECOMMENDATIONS . VI-1 

A.  Conclusions . VI-1 

B.  Recommendations . VI-2 


iii 


LIST  OF  EXHIBITS 


EXHIBIT 

1-1 

II- l 

1 1-  2 

III- l 
1 1 1-2 

III- 3 

IV-  1 
IV- 2 

IV-  3 

V- l 
V-2 
V-3 
V— 4 
V-5 
V-6 
V-7 
V-8 
V-  9 
V-10 

V-ll 

V-l  2 
V-l  3 


PAGE 

Man— days  of  Effort  to  Perform  the  Contract  Design 
of  Various  Destroyer  Types  Over  the  Last  30  Years  1-4 


Government  Directives  and  Reviews  Relating  to 
Concurrency . II-7 

Major  Defense  Systems  Acquisition  Process  ....  II-9 

Joint  Cost/Schedule  Risk  Profile . III-4 

Cost  and  Schedule  Contours . Ill  — 5 

Risk  Contours . III-6 

Representative  Acquisition  Activities  .  IV-3 

Descriptive  Model  .  IV-6 

Steps  in  Concurrency  Analysis  Model  .  IV-9 

Organizations  Responding  to  PM  Direction  ....  v-5 

Program  Management  Organization  .  v-6 

Typical  SHAPM  Organization  .  v-7 

Ship  Design  Organization  .  V-8 

Combat  System  Engineering  Organization  .  v-9 

Example  of  Summary  Schedule  .  V-12 

Ship  Design  Work  Breakdown  Structure  .  V-13 

Combat  System  Breakdown  Structure  .  V-14 

Support  Systems  Work  Breakdown  Structure  ....  V-15 

The  Degree  of  Technological  Uncertainty  at 
Progressive  Stages  (Risk)  .  v-21 

Relationship  of  Concurrency  Options  to 

Alternative  Schedules  .  v-?4 


Cost  Risk  Considerations  in  System  Design  ....  V-26 

Schedule  Risk  Considerations  .  v-27 


IV 


LIST  OF  EXHIBITS  (Cont'd) 


EXHIBITS  PAGE 

V-14  Evaluation  of  Alternative  Schedule  .  V-29 

V-15  The  Degree  of  Concurrency  Realized  as  a  Function 

of  the  Percent  of  the  Baseline  Time  Saved  ....  V-31 


v 


I.  INTRODUCTION 

MCR  was  tasked  by  the  Office  of  Naval  Research  to  develop 
techniques  to  enable  Project  Managers  (PMs)  for  major  acquisi¬ 
tions  to: 

•  determine  where  it  may  be  possible  to  shorten  the 
acquisition  cycle  by  the  use  of  concurrency;  and 

•  quantify  the  risk  associated  with  such  a  schedule 
change . 

MCR 1 s  objective  for  Phase  I  of  the  proposed  two-phase 
study  has  been  to  develop  guidelines  to  be  used  by  the  PM  to: 

•  •  identify  and  select  program  activities  amenable  to 

concurrent  scheduling,  and 

•  generate  checklists  that  can  be  used  in  evaluating 

the  cost  and  schedule  risks  associated  with  concurrency 
decisions . 

In  addition  to  accomplishing  these  tasks,  we  have  also 
made  recommendations  for  the  further  development  of  planning 
tools  required  by  PMs. 

A.  BACKGROUND 

The  first  major  weapon  system  procurement  in  the  U.S. 
occurred  on  March  27,  1794  when  Congress  authorized  the  build¬ 
ing  of  six  large  frigates  by  the  U.S.  War  Department.  Some 
seventeen  months  later,  six  keels  were  laid.  Due  to  schedule 
slippage  and  cost  overruns,  the  program  was  cut  back  to  three 
frigates. — ^  Now,  almost  two  hundred  years  later,  the  problems 
of  schedule  slippage  and  cost  overrun  are  being  "rediscovered." 

1/  Decision-Making  for  Defense,  Charles  J.  Hitch,  University 
of  California  Press,  Los  Angeles,  CA,  1965. 
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The  difference  now  is  that  the  concept  of  "concurrency"  is  be¬ 
ing  suggested  as  a  solution. 

General  Bernard  Schriever  is  credited  with  coining  the  term 
"concurrency"  in  early  1958  while  describing  the  Air  Force  Bal¬ 
listic  Missile  (AFBM)  program.  A  1958  report—'  described  this 
program  and  the  Navy's  Polaris  program  as  successful  examples 
of  the  "concept  of  concurrency."  Throughout  the  1960s,  several 
programs,  including  several  which  were  cancelled,  such  as  MBT-70, 
F— 111B,  CONDOR  and  CHEYENNE,  allowed  production  efforts  to  begin 
prior  to  completion  of  full-scale  development.  However,  enough 
problems  had  occurred  that  were  allegedly  due  to  concurrent 
scheduling  that  by  the  Spring  of  1969,  then  Deputy  Secretary 
of  Defense  David  Packard  promulgated  the  philosophy  of  "fly- 
before-buy."  Several  studies  also  echoed  similar  concerns  and 
advocated  producing  only  after  the  system  development  had  been 
completed.—  The  formal  guidance  came  in  the  1971  version  of 
DoD  Directive  5000.1  which  noted  that  one  should  not  propose 
"...  unnecessary  overlapping  or  concurrency. 

By  1977,  however,  the  concept  of  concurrency  was  beginning 
to  be  reestablished.  Dr.  Richard  DeLauer,  then  of  TRW,  Inc. 

2/  "The  United  States  Guided  Missile  Program,"  prepared  by  the 
Legislative  Reference  Service  of  the  Library  of  Congress  for 
the  Senate  Armed  Services  Committee,  referenced  in  the  Con¬ 
gressional  Record,  January  27,  1959. 

3/  Examples  are  the  RAND  Report,  "System  Acquisition  Strate¬ 
gies,"  by  Robert  Perry,  in  June  1971;  and  the  Blue  Ribbon 
Defense  Panel  Report  of  July  1970. 

4/  DoDD  5000.1,  "Acquisition  of  Major  Defense  Systems,"  13 
July  1971. 
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and  currently  Under  Secretary  of  Defense  for  Research  and  En¬ 
gineering,  chaired  a  Defense  Science  Board  ( DSB )  Summer  Study 
to  examine  the  problem  of  the  lengthening  acquisition  cycle.— ^ 

The  report  noted  that  it  often  takes  12—13  years  to  complete 
the  acquisition  cycle  from  Program  Initiation  through  Deploy¬ 
ment.  In  fact  the  average  time  to  DSARC  II  grew  from  two  years 
in  1950  to  five  years  as  of  1977  according  to  the  report.  An 
illustration  of  some  of  the  growth  in  the  acquisition  cycle  for 
ships  can  be  seen  in  Exhibit  I— 1,  which  shows  the  drastic  increase 
in  just  the  contract  design  phase.  Of  more  importance  was 
the  report's  observation  that  programs  are  not  cancelled  for 
reasons  of  concurrency,  but  rather  for  reasons  of  a  technical 
or  political  nature,  or  because  of  changes  in  requirements. 

Two  recent  articles  describe  the  advantages  of  concur- 
6  / 

rency.—  In  addition,  DoD  Instruction  5000.2  now  notes  that: 

.  .  .  consideration  (should  be  given)  to  minimizing  acqui¬ 

sition  cycle  time  by  planned  concurrency.  This  may  include 
increasing  funding,  overlapping,  combining  or  omitting  the 
phases  of  the  acquisition  process,  or  overlapping  or  com¬ 
bining  developmental  T&E  with  operational  T&E .  The  amount 
or  degree  of  such  concurrency  should  be  based  on  the  extent 
of  the  potential  savings  in  acquisition  time  balanced  against 
technical,  cost  and  supportability  risks  and  national  urgency 
in  each  acquisition  program. 7/ 

In  order  to  effectively  use  concurrency  as  an  approach 

for  shortening  the  acquisition  cycle,  the  decision-maker  must 

5/  "Acquisition  Cycle  Task  Force  Report,"  Defense  Science 
Board  Summer  Study,  15  March,  1978. 

6/  "Concurrency,"  Robert  Gibson,  Defense  Systems  Management 
Review ,  Autumn  1979;  "Concurrency  Today  in  Management , " 

Thomas  Harvey,  Defense  Systems  Management  Review,  Winter 

1980.  - 

2/  DoDI  5000.2,  "Major  Systems  Acquisition  Procedures", 

19  March  1980  (currently  being  revised,  although  this 
statement  remains  in  the  draft). 
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Exhibit  1-1.  MAN-DAYS  OF  EFFORT  TO  PERFORM  THE  CONTRACT 
DESIGN  OF  VARIOUS  DESTROYER  TYPES  OVER  THE  LAST  30  YEARS 


be  able  to  ascertain  the  potential  impacts,  particularly  cost 
and  schedule  risks,  of  his  decisions.  There  are  currently  no 
techniques  available  to  the  decision-maker  which  are  specifi¬ 
cally  designed  to  be  used  in  these  analyses.  However,  in  order 
to  effectively  use  concurrency,  such  techniques  are  needed. 


B.  APPROACH 

The  current  phase  of  this  study  was  composed  of  three 
major  analytical  tasks: 

•  The  first  task  involved  background  research  into  the 
extent  of  the  availability  of  tools  and  techniques  to 

•  assist  the  PM.  In  addition,  attention  was  given  to 

determining  if  previous  or  current  research  in  the 
acquisition  process  had  addressed  the  problem  of  con¬ 
currency.  The  background  research  was  accomplished 
by  way  of : 

a  literature  search, 

a  survey  of  acquisition  analyses,  and 

-  an  examination  of  high-level  direction. 

A  summary  of  this  research  is  presented  in  Section  II 
of  this  report; 

•  The  second  task  in  this  study  focused  on  developing  a 
descriptive  model  to  be  used  in  making  concurrency 
decisions;  and 

•  The  third  task  concentrated  on  elaborating  on  the 
descriptive  model  by  developing  methodologies  to  speci¬ 
fically  analyze  the  risk  of  using  concurrency  to  shorten 
the  acquisition  cycle.  These  methodologies  were  designed 
to : 

consider  the  elements  of  risk  at  each  phase  of  the 
acquisition  cycle; 

consider  the  concurrency  alternatives  available 
to  the  PM  at  each  phase,  and 

determine  the  applicability  of  existing  risk 
analysis  techniques. 
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The  discussion  of  the  risk  analysis  tools  and  techniques  is 
presented  in  Section  III,  while  the  description  of  the  model 
and  the  supporting  methodologies  are  provided  in  Section  IV 
of  this  report. 
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II.  SUMMARY  OF  BACKGROUND  RESEARCH 


The  first  step  in  this  study  was  the  identification  of 
analyses  that  had  already  been  performed  in  this  acquisition 
research  area.  Also  of  interest  were  any  directives  which  had 
been  provided  to  decision  makers  on  how  to  consider  the  ques¬ 
tion  of  concurrency,  and  if  there  were  any  existing  tools  or 
techniques  useful  in  the  analysis  of  concurrency.  The  basic 
approach  taken  in  this  research  is  described  below. 

A .  APPROACH  TO  BACKGROUND  RESEARCH 

MCR's  background  research  into  concurrency  focused  on: 

•  directives,  studies,  and  papers  related  to  acquisi¬ 
tion  scheduling  or  planning  which  specifically  address 
concurrency;  and 

•  tools  and  techniques  used,  or  which  could  be  used, 
in  acquisition  scheduling. 

This  research  was  accomplished  through  the  three-pronged 
approach  of: 

•  a  literature  search  focusing  on: 

acquisition  scheduling,  and 
concurrency; 

•  an  informal  survey  of  organizations  involved  in  ac¬ 
quisition  research;  and 

•  a  review  of  government  directives  related  to  acquisi¬ 
tion  planning. 

B .  SUMMARY  OF  RESEARCH  FINDINGS 

The  following  are  the  most  significant  findings  of  MCR's 
background  research.  These  findings  have  been  arranged  accord¬ 
ing  to  general  topic. 
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1. 


Definition  of  Concurrency 


There  is  no  universally  accepted  or  consistently  used 
definition  of  concurrency  within  the  context  of  weapon  system 
acquisition  program  planning.  There  are,  however,  multiple  inter¬ 
pretations  of  the  term. 

The  1977  DSB  study—'  restricted  its  definition  of 
concurrency  to: 

The  conduct  of  the  steps  leading  to  production  for  inven¬ 
tory  before  the  end  of  the  full-scale  development  time 
span. 

In  examining  the  literature,  however,  one  finds  the  most  fre¬ 
quent  interpretations  of  the  term  concurrency  to  include: 

•  parallel  (back-up)  technological  development, 

•  simultaneous,  but  independent,  subsystem  development 
and  testing, 

•  co-production,  and 

•  overlap  of  dependent,  normally  sequential  activities. 

In  addition,  in  examining  alternatives  to  reduce  the  acquisition 
cycle  time,  it  is  clearly  not  sufficient  to  concentrate  solely 
on  the  development/production  overlap. 

Concurrency  should  be  examined  in  light  of  two  alter¬ 
native  planning  concepts:  ^ 

•  schedule  protection  -  This  concept  recognizes  that 

the  need  to  extensively  revise  the  program  schedule 
may  occur  in  the  future.  The  PM  can  attempt  to  avoid 
a  crisis  later  on  by  identifying  concurrency  options 
and  scheduling  alternatives  before  a  crisis  occurs. 

8/  The  Defense  Science  Board  Summer  Study,  "Acquisition  Cycle 
Task  Force  Report,"  15  March  1978. 
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schedule  compression  -  Frequently,  despite  the  best 
planning,  a  schedule  must  be  revised  due  to  conditions 
such  as  earlier  schedule  slippage  resulting  in  less 
time  available  for  the  remaining  activities,  the  moving 
earlier  in  time  of  a  deadline,  the  avoidance  of  cost 
increases  due  to  a  longer  acquisition  cycle,  etc.  Any 
or  all  of  these  occurrences  can  result  in  the  need  to 
limit  an  already  existing  or  imminent  crisis. 


2 .  Documentation  Relating  to  Concurrency 

There  are  few  studies  which  have  specifically  addressed 

•  the  uses  of  concurrency, 

•  the  specific  effects  of  concurrency  on  program  ac¬ 
quisition,  or 

•  the  application  of  concurrency  in  program  scheduling. 
Concurrency  is  used  to  varying  degrees 'in  virtually 

all  programs,  even  if  only  as  a  means  of  providing  on-going  pro¬ 
gress  during  decision  and  review  periods.  However,  its  use  as  a 
method  of  compensating  for  resource  reductions  and/or  shortages 
has  not  been  extensively  documented.  Because  of  this,  it  is  dif¬ 
ficult  to  determine  where,  and  under  what  circumstances,  the  use 
of  concurrency  as  such  a  tool  has  been  successful. 

In  the  past,  concurrency  has  been  considered  the  source 
or  a  potential  source,  of  substantial  problems  in  the  acquisition 
of  various  weapon  systems.  This  has  resulted  in  the  tendency 
to  avoid  using  concurrency,  or  in  disguising  and  minimizing 
the  use  of  it  in  acquisition  planning. 

The  problem  of  effectively  using  concurrency  is 
constrained  by  the  general  lack  of  training  given  to  project 
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administrators  and  managers  who  plan  and  evaluate  program  sche¬ 
dules.  MCR's  investigation  indicated  that  although  tools  are  avail¬ 
able  for  developing  and  analyzing  certain  aspects  of  schedules 
and  networks,  they  have  not  been  put  in  the  context  of  a  frame¬ 
work  for  analyzing  the  impacts  of  concurrency.  The  result  is 
that  PMs ,  or  the  groups  in  their  staffs  responsible  for  reviewing 
and  adjusting  the  acquisition  schedule,  are  forced  to  make  deci¬ 
sions  without  being  able  to  analyze  the  risks  or  impacts  of  their 
decisions . 

In  the  past  PMs  have  been  forced  to  resort  to  con¬ 
current  scheduling  in  order  to  compensate  for  schedule  delays. 
Frequently  this  has  required  the  imposition  of  concurrency 
late  in  the  project,  when  the  precedence  relationships  among 
activities  are  most  stringent,  and  the  risk  of  failure  is  most 
costly . 

3.  Previously  Suggested  Alternatives  to  Reduce  Acquisi- 
tion  Time 

The  following  are  some  of  the  alternatives  suggested 
by  various  sources: 

•  reduction  of  in-service  review, - 

•  reorganization  of  the  DSARC  process  and  reassignment 
of  hierarchical  responsibilities  ,- 

•  explicit  emphasis  on  developing  techniques  for  shor¬ 
tening  the  acquisition  cycle ; 

•  increased  emphasis  on  front-end  analysis  and  develop¬ 
ment  of  design  philosophies; 

•  committment  to  freezing  designs,  development  of  sche¬ 
duled  Top  Level  Requirements/Top  Level  Specifications 
( TLR/TLS ) ,  and  the  application  of  Pre-Planned  Product 

3 

Improvement  (P  I); 
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•  increased  coordination  of  the  DSARC  and  PPBS  processes, 
and 

•  development  of  techniques  for  quantitatively  analyzing 
the  impacts  and  risks  of  program  schedule  changes. 

Many  of  these  alternatives  have  been  specifically  addressed  by 

the  DoD  Acquisition  Improvement  Program  promulgated  by  Deputy 

Secretary  of  Defense  Carlucci.—' ' 

4 .  Pros  and  Cons  of  Concurrency 

The  basic  arguments  for  and  against  the  use  of  concur¬ 
rency  can  be  summarized  as  follows: 

•  Potential  Advantages: 

attainment  of  an  earlier  IOC, 

-  increased  likelihood  of  meeting  intermediate 
goals  and  thresholds, 

lower  overhead  costs, 

work  force  continuity,  and 

-  increased  worker  motivation. 

•  Potential  Disadvantages: 

possible  premature  committment  to  high-cost  program 
elements, 

excessive  and  higher  cost  changes  in  design 
after  production  has  commenced, 

unreliable  equipment  in  service,  and 

degradation  of  training  because  of  multiple 
configurations  and  faulty  systems. 

The  problem  with  any  discussion  of  concurrency,  how¬ 
ever,  is  that  of  over-generalization.  A  given  program  can 
easily  be  affected  by  threat  induced  changes  in  IOC,  overly 

9/  In  Memorandum:  "Improving  the  Acquisition  Process,"  Frank 
C.  Carlucci,  April  30,  1981. 
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ambitious  schedules,  redefinition  of  the  need  and  changing  tech¬ 
nologies  to  meet  that  need  resulting  in  program  restructuring, 
as  well  as  the  need  to  compensate  for  program  delays.  One  of 
the  overriding  conclusions  of  MCR's  research,  however,  is  that 
continuous  risk  analysis  is  required,  as  is  careful  planning  of 
funding  support  and  program  stability.  The  Carlucci  initiatives 
collectively  solve  many  of  the  problems  previously  perceived  as 
overriding  disadvantages. 


5.  Official  Directives  and  Guidance 

Exhibit  II-l  lists  the  major  government  directives 
considered  to  have  the  most  significant  influence  on  Navy  PMs 1 
use  of  concurrency  in  their  programs.  The  memo  of  31  March  1982 
by  Deputy  Secretary  of  Defense  Carlucci  outlined  32  initiatives 
planned  to  improve  the  defense  system  acquisition  process.  Of 
these  32  initiatives,  seven  were  interpreted  as  influencing  the 


use  of  concurrency: 

•  Action  6  -  Budget  to  Most  Likely  Cost, 

•  Action  9  -  Improve  System  Support  and  Readiness, 

•  Action  11  -  Budget  Funds  for  Technological  Risk, 

•  Action  12  -  Front-End  Funding  for  Test  Hardware, 

•  Action  21  -  Standard  Operational  and  Support  Systems, 

•  Action  30  -  Give  the  Program  Manager  More  Control  of 

Support  Resources,  Funding  and  Execution, 
and 

•  Action  31  -  Improve  Reliability  and  Support  for  Short¬ 

ened  Acquisition  Cycles. 
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AGENCY 


AGENCY 

DIRECTIVES  AND  REVIEWS 

OMB 

Circular  A-109 

OSD 

DODD  5000.1  (Major  System  Acquisition) 

DODI  5000.2  (Major  System  Acquisition  Proce¬ 
dures  ) 

DODI  5000.3  (Test  and  Evaluation) 

DODI  5000.39  (Acquisition  &  Management  of 

ILS  Support) 

SECNAV 

SECNAVINST  5000.1a  (System  Acquisition/Navy ) 

OPNAV 

OPNAVINST  5000.42a  (Weapon  System  Selection  & 
Planning ) 

OPNAVNOTE  5000  (Acquisition  Documentation  Re¬ 
duction  ) 

NAVMAT 

NAVMAT  P-9494  (Navy  Program  Manager's  Guide) 

NAVSEA 

NAVSEAINST  9060.4  (Ship  Acquisition  Process) 
Ship  Acquisition  Reef  Points 

Ship  Acquisition  Contracts  Administration 
Manual 

OTHER 

DSMC  Seminar  on  Impact  of  New  Direction  on 
the  Acquisition  Process 

Exhibit 

II-l.  SELECTED  GOVERNMENT  DIRECTIVES  AND 

REVIEWS  RELATING  TO  CONCURRENCY 
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Exhibit  II-2  indicates  the  major  changes  in  the  DSARC 
review  process,  based  on  the  current  version  of  DoDD  5000.1,  "Major 
Systems  Acquisitions." 


6 .  PM  Concurrency-Related  Needs 

Based  on  MCR's  research,  several  basic  analytical 
needs  were  identified  as  required  to  be  fulfilled  in  order  for 
the  PM  to  effectively  use  concurrency  in  a  program  schedule. 

He  must  be  able  to: 

•  define  the  amount  or  degree  of  concurrency  deemed 
desireable  for  his  particular  program; 

•  determine  the  set  of  program  activities  which  can 
be  concurrently  scheduled  considering:- 

-  the  amount  of  dependence  on  activities  in  the 
previous  phase, 

whether  there  are  high  costs  associated  with 
the  particular  activity, 

-  whether  failure  to  meet  the  schedule/cost  ob¬ 
jectives  of  the  activity  will  produce  long¬ 
term  increases  in  the  program  costs,  and 

-  whether  failure  to  meet  the  schedule/cost  ob¬ 
jectives  of  the  activity  will  produce  long¬ 
term  increases  in  the  program  schedule; 

•  evaluate  the  cost— risk  impact  on  program  goals, 
thresholds  and  requirements,-  and 

•  justify  these  decisions  to  the  Service  hierarchy  and 
OSD. 
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Exhibit  II-2 .  MAJOR  DEFENSE  SYSTEMS  ACQUISITION  PROCESS 


Ill . 


OVERVIEW  OF  RISK  ANALYSIS  TOOLS  AND  TECHNIQUES 


In  considering  the  use  of  concurrency  as  a  scheduling 
option,  it  is  important  to  be  able  to  analyze  the  risks 
associated  with  each  scheduling  option.  A  body  of  knowledge 
already  exists  to  allow  analysis  of  some  of  the  risks  associ¬ 
ated  with  concurrently  scheduling  program  activities.  However, 
in  order  to  apply  this  body  of  knowledge,  it  is  first  necessary 
to  identify  and  order  the  components  of  risk  analysis  and  the 
tools  and  techniques  applicable  to  analyzing  schedule  concurrency 
risks . 

A.  COMPONENTS  OF  RISK  ANALYSIS 

Typically,  risk  analysis  is  used  to  assess  the  degree  to 


which  a  proposed  system  is  likely  to  achieve  its  predicted  per¬ 
formance  within  cost  and  schedule  goals.  In  conducting  a  risk 


analysis  it  is  essential  to  consider  these  three  aspects: 


10/ 


•  Risk  Assessment  -  the  identification  of  the  degree 
of  risk  with  respect  to  the  realism,  soundness,  and 
credibility  of  the  program's  cost  and  schedule,  and 
the  system's  performance. 

•  Risk  Management  -  the  development  of  a  plan  for 
managing  all  types  of  risk  (risk  minimization  plan) 
as  a  function  of  time  (i.e..  Acquisition  Milestones 
I,  II,  and  III).  Methods  of  minimizing  risk,  such 
as  quality  assurance,  and  other  hedges  against  new 
technology  failure  are  considered  here. 

•  Risk  Demonstration  -  the  formulation  of  a  test  and 
evaluation  demonstration  plan  will  allow  early  iden¬ 
tification  of  risks.  Specifically,  the  steps  re¬ 
quired  to  reduce  high  risk  program  elements  to  ac¬ 
ceptable  levels  as  well  as  the  cost  of  doing  so  are 
demonstrated . 


10/  "Cost-Risk  Procedures  for  Weapon  System  Risk  Analysis," 
Gerald  McNichols,  Proceedings  Annual  Reliability  &  Maint- 
tainability  Symposium,  Institute  of  Electrical  and  Elec¬ 
tronics  Engineers,  Inc.,  New  York,  January  1981. 
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A  risk  assessment  includes  not  only  an  evaluation  of  the 
likelihood  of  success,  but  also  must  include  assessment  of  the 
consequences  of  failure  in  measurable  terms,  usually  dollars. 

Hence  the  concept  of  a  "cost-risk  analysis"  becomes  of  interest. 
The  analysis  of  concurrency,  as  part  of  the  overall  development 
of  acquisition  strategies,  is  part  of  the  risk  assessment  pro¬ 
cess.  It  does  not  obviate  the  need  for  continued  risk  manage¬ 
ment  or  risk  demonstration. 

B .  AVAILABLE  ANALYTICAL  TOOLS  AND  TECHNIQUES 
.  Several  models  are  currently  available  to  assist  in  the 
analysis  of  acquisition  schedules.  These  are  typically  net¬ 
work  analysis  or  critical  path  techniques.  Some  of  the  best 
known  include: 

•  Gantt  Charting, 

•  Critical  Path  Method  (CPM), 

•  Program  Evaluation  and  Review  Technique  (PERT), 

•  Program  Evaluation  and  Review  Technique/Cost  (PERT/- 

COST) , 

•  Graphical  Evaluation  and  Review  Technique  (GERT), 

•  Venture  Evaluation  and  Review  Technique  (VERT), 

•  Simplified  Network  Analysis  Portrayal  for  Planning 
and  Control  (SNAP),  and 

•  Risk  Information  for  Schedule  and  Cost  Analysis 

(RISCA). 

Many  more  techniques  are  currently  in  use. 

The  Services  have  not  attempted  to  standardize  or  institu¬ 
tionalize  one  specific  technique  for  Project  Managers'  use.  Al¬ 
though  there  has  been  a  move  to  advocate  the  use  of  the  Total  Risk 
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Assessing  Cost  Estimate  (TRACE)  methodology,  or  a  similar  method, 
by  all  Services,  this  model  only  considers  cost  uncertainty,  not 
schedule  uncertainty . 

A  basic  tenet  of  the  concurrency  analysis  methodology  pre¬ 
sented  in  this  report  is  that  there  is  no  need  to  develop  new 
techniques  for  analyzing  project  schedule  networks  and  the  risks 
associated  with  them.  Rather,  the  need  is  for  an  analytical  frame¬ 
work  in  which  a  PM  can  apply  them.  It  is  up  to  the  PM  to  select 
the  technique  most  compatible  with  the  specific  characteristics  of 
his  project. 

Conceptually  the  cost/schedule  risk  problem  can  be  illustrated 
by  Exhibits  III-l,  III-2  and  III-3.  A  baseline  program  schedule 
(presumably  "optimal”  in  some  sense)  has  a  period  of  performance 
and  level  of  funding  associated  with  it.  It  also  has  implicitly 
(at  a  point  in  time)  a  chance  of  requiring  additional  time  or  cost. 
If  a  PM  is  willing  to  accept  a  non-zero  chance  of  exceeding  his 
funding  level  or  time  estimate,  then  he  can  begin  to  trade-off  cost/ 
schedule/risk.  For  example,  suppose  a  52-month  program,  funded  at 
$52  million  has  a  10%  chance  of  exceeding  those  values.  Then  the 
schedule  can  be  shortened  by  additional  funding,  while  maintaining 
that  same  10%  risk  level.  Alternatively,  the  funding  level  can  be 
maintained  or  even  reduced  as  the  schedule  is  compressed  simply  by 
accepting  an  increased  risk  of  exceeding  those  values.  This  is  the 
risk  assessment  process.  By  using  a  proper  risk  management  plan, 
however,  the  initially  higher  risk  level  can  be  monitored  and 
minimized  over  time.  Risk  demonstration,  through  well  designed 


1 1 1-3 


LEVEL  OF  FUNDING  ($M) 


RISK  OF 
EXCEEDING 
TIME  OR  COST 


Exhibit  III-l.  JOINT  COST/SCHEDULE  RISK  PROFILE 
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Risk  of  Exceeding 
Level  of  Funding 
(%) 


Risk  of  Exceeding 
Period  of  Performance 
(%) 


Level  of  Funding 
($M) 


Exhibit  I I 1-2.  COST  AND  SCHEDULE  CONTOURS 
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Level  of 
Funding 
( $M) 


Exhibit  III-3 .  RISK  CONTOURS 
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test  procedures,  may  result  in  a  program  lower  in  cost  and  shorter 
in  duration  than  the  inital  "optimal"  baseline  schedule. 

The  concurrency  analysis  model  incorporates  these  components 
of  risk  analysis.  Initial  risk  "targets"  are  set  as  part  of  the 
development  of  the  input  information  for  generating  the  alternatives 
while  the  cost  and  schedule  risks  associated  with  the  alternative 
schedules  are  assessed  in  the  evaluation  of  the  alternatives.  On¬ 
going  risk  management  is  perceived  as  being  an  internal  part  of 
applying  this  methodology  as  part  of  the  planning  review  process 
required  in  the  project.  Finally,  the  risk  is  demonstrated  through 
the  two-part  process  of  generating  and  evaluating  alternative  sche¬ 
dules  and  monitoring  the  applicability  of  those  alternatives  through 
the  project. 
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IV.  DESCRIPTION  OF  MCR  CONCURRENCY  ANALYSIS  MODEL 


MCR's  effort  in  this  Phase  I  study  was  directed  toward 
designing  a  model  to  assist  the  PM  in  making  concurrency  deci¬ 
sions.  The  initial  step  in  this  process  was  the  definition  of 
the  scope  of  the  model.  The  model  must  be  sensitive  to  the 
characteristics  of  a  schedule  since  its  primary  purpose  is  the 
review  and  revision  of  project  schedules.  The  application  of 
the  model  is  left  to  the  PM,  as  is  the  scope  of  the  change  or 
scope  of  the  concurrency,  which  is  dependent  on  such  project- 
specific  features  as  magnitude  of  the  constraints,  phase  of  the 
schedule,  etc.  These  characteristics  are  specifically  addressed 
in  the  model  description  below. 

A .  P ROJECT  SCHED U L E  COMPONENTS 

In  attempting  to  understand  what  concurrency  involves, 
specific  factors  and  criteria  must  be  developed  for  consider¬ 
ing  project  activities  and  decisions  required  of  the  Project 
Manager.  The  basic  components  in  creating  project  schedules 
must  be  identified.  The  project  activities  and  events  can  be 
considered  in  light  of  these  components. 

Specifically,  it  is  necessary  to  consider: 

•  Phases  -  acquisition  phases  such  as  Concept  Explor¬ 
ation,  Demonstration  and  Validation,  Full  Scale  De¬ 
velopment,  and  Production. 

•  Functions  -  major  categories  of  work  performed  in, 
or  under  the  direction  of,  the  Project  Management 
Office  such  as  Technical  Management,  Logistics 
Management,  Business  Management,  etc., 

•  Task  Areas  -  subtasks  of  functional  work  such  as 
hardware  design,  software  design,  test  and  evalua¬ 
tion,  etc.  under  Technical  Management, 
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•  Events  -  end  points  such  as  document  delivery,  de¬ 
sign  review  meetings,  milestones,  and  initiation 
of  development  of  documents, 

•  Activities  -  efforts  involved  in  preparing  for  a 
particular  event,  or  following  a  starting  event, 
such  as  preparation  of  a  baseline  and  review  of  a 
procurement  plan,  and 

•  Organizations  -  groups  responsible  for  performing 
activities  such  as  the  Project  Management  Office 
functional  groups  or  contractors. 

These  must  be  presented  in  terms  of  time  in  order  to  produce  a 

schedule . 

In  addition  to  these  basic  components,  a  project  schedule 
is  individualized  based  on  two  other  considerations: 

•  System  Type  -  generic  type  of  weapon  system  related 
to  the  project  schedule,  e.g.,  ship,  aircraft, 
missile. 

•  Subsystems  -  level  three  work  breakdown  structure  ele¬ 
ments  of  hardware,  as  defined  by  MIL-STD  881A,  which 
may  be  on  different  developmental  schedules,  but  which 
collectively  constitute  a  viable  weapon  system. 

Exhibit  IV-1  illustrates  representative  acquisition  activities  for 

a  notional  ship  acquisition  project. 

In  examining  the  degree  of  desirable  concurrency  for  a 
particular  project  many  factors  must  be  considered.  The  fol¬ 
lowing  considerations  are  briefly  summarized  here: 

•  factors  influencing  the  applicability  of  concurrency, 

•  acquisition  cycle-related  problems, 

•  previously  suggested  alternatives, 

•  pros  and  cons  of  increased  concurrency,  and 

•  factors  for  changing  project  concurrency. 
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Exhibit  IV-1.  REPRESENTATIVE  ACQUISITION  ACTIVITIES 


It  is  not  clear  that  concurrency  is  applicable  to  all  sys¬ 
tem  acquisitions.  Development  factors  such  as  design  status, 
familiarity  of  technology,  environmental  characteristics,  pro¬ 
ject  personnel  experience,  and  contractor  availability/experience , 
and  production  factors  such  as  production  resource  availability/ 
manufacturing  capability,  and  level  of  previous  program  involve¬ 
ment  are  all  important.  But  so,  too,  is  the  discipline  required 
(risk  management)  of  scheduling  far  in  advance  of  actual  require¬ 
ment  (i.e.,  consider  production  and  logistics  problems  very  early 
in  the  cycle).  Risks  of  technological  advancement  or  lack  of 
maturity  of  design  balanced  against  high  development  cost  or 
high  cost  uncertainty  can  doom  a  project  and  require  higher 
costs  of  maintaining  low-risk  alternatives.  There  is  a  complex 
hierarchy  of  responsibility  and  review  that  also  contributes  to 
the  problem  rather  than  to  the  solution.  In  addition  to  these 
needs  the  program  schedule  must  also  be  analyzed  in  terms  of  its 
sensitivity  to  external  forces  such  as  political  and  budgetary 
decisions . 

B.  OVERVIEW  OF  THE  MODEL 

The  approach  taken  in  developing  a  tool  to  assist  the  PM  in 
making  concurrency— related  decisions  has  been  to  construct  a  logical 
framework  for  utilizing  a  progresive  accumulation  and  refinement  of 
data.  The  model  itself  is  designed  to  be  neither  weapon  system 
specific,  nor  sensitive  to  a  particular  level  of  detail.  Rather, 
it  is  applicable  to  any  system,  with  appropriate  tailoring,  and 
any  level  of  organizational  detail. 


Exhibit  IV-2  shows  the  structure  of  MCR's  descriptive 
model.  This  model  is  composed  of  seven  basic  steps  to  be 
performed  by,  or  under  the  direction  of,  the  Project  Manager. 

The  first  step  involves  the  development  of  the  initial  project 
schedule  which  forms  the  basis  for  concurrency  and  cost/schedule 
risk  analysis.  It  also  includes  the  formulation  of  the  rules 
and  criteria  for  performing  the  analyses,  and  the  identification 
of  an  initial  set  of  concurrency  options. 

Having  set  up  the  problem,  the  second  step  concerns  the 
considerations  of  the  constraints  that  the  PM  must  respond  to 
in  the  schedule.  These  constraints  may  be  pre-existing  or 
newly  imposed,  endogenous  or  exogenous  to  the  project.  This 
step  is  closely  related  to  the  third  step,  determining  the 
reason  for  considering  concurrency.  In  evaluating  the  con¬ 
straints  the  PM  must  determine  the  desirable  scope  of  the  con¬ 
currency,  i.e.,  the  phases,  functions,  task  areas,  and  activi¬ 
ties  affected  by  the  implementation  of  concurrency.  In  recog¬ 
nizing  the  motivation,  the  PM  is  also  considering  the  ultimate 
purpose  to  be  achieved  by  using  concurrency  as  a  scheduling 
mechanism,  as  well  as  the  circumstances  driving  the  decision, 
i.e.,  earlier  schedule  slippage,  protection  of  the  remaining 
schedule,  incorporation  of  changing  direction,  etc. 

In  the  fourth  step,  the  PM  determines  the  magnitude  of 
acceptable  risk  to  be  considered  in  developing  and  selecting 
alternatives.  This  narrows  down  the  set  of  possible  alterna¬ 
tive  schedules  which  could  fulfill  the  requirements.  It  is  at 
this  point  that  decisions  are  made  about  acceptable  degrees  of 
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Exhibit  IV- 2.  DESCRIPTIVE  MODEL 
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concurrency  and  risk.  Based  on  the  analysis  performed  in  the 
previous  steps,  it  is  possible  that  there  may  be  more  than  one 
set  of  concurrent  activities  in  an  alternative,  each  of  which 
will  have  to  be  decided  upon. 

The  fifth  step  involves  the  development  of  alternative 
schedules  which  are  within  the  scope  of  the  preceeding  con¬ 
straints  and  risks.  A  variety  of  alternatives,  addressing  one 
or  more  of  the  previously  selected  sets  of  concurrency  options, 
may  be  developed. 

The  companion  to  this  step  is  the  analysis  of  the  risks 
associated  with  each  alternative,  performed  in  the  sixth  step. 
The  evaluation  of  the  alternatives  is  performed  using  check¬ 
lists  tailored  to  the  particular  characteristics  of  the  sys¬ 
tem  type,  the  stage  in  the  development  of  the  system,  and  the 
particular  task  areas  and  activities  involved.  Development  of 
these  structured  checklists  is  begun  with  the  selection  of  the 
concurrency  options  in  step  one  and  is  continued  through  each 
step,  incorporating  the  refined  direction  that  is  being  devel¬ 
oped  in  this  process.  They  are  tailored  to  respond  to  the 
PM's  information  needs  necessary  to  make  an  actual  decision. 

Having  evaluated  and  scored  the  alternative  scheduling 
options,  the  final  step  is  the  selection  of  the  alternative 
which  most  adequately  satisfies  the  requirements  at  the  time 
of  the  decision.  Using  the  basic  criteria  developed  in  the 
first  step,  and  refined  for  the  actual  decision,  the  PM 
trades-off  the  options  presented  in  the  alternatives  among 
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cost,  schedule,  and  risk  in  the  program  environment.  The  ul¬ 
timate  selection  is  the  revised  schedule.  Although  a  single 
alternative  may  be  selected  in  this  process,  it  is  often  the 
case  that  other  viable  alternatives  have  been  developed  and 
should  be  monitored  in  the  process  of  subsequent  schedule  reviews. 

Initially,  several  assumptions  are  made: 

•  the  Project  Manager  is  assumed  to  have  a  Baseline 
Schedule  ,- 

•  funding  and  schedule  constraints  can  be  defined, 

•  resource  estimates  (e.g.,  of  time,  cost  and  manpower 
levels)  can  be  made  for  each  schedule  component, 

•  analysis  of  alternative  schedules  representing  rela¬ 
tively  fixed  performance  will  be  performed,-  and 

•  concurrency  can  be  meaningfully  considered  in  terms 
of  potential  savings  in  time  versus  cost  risk. 

The  Top  Level  Hypotheses  (TLH)  are  simply  that: 

•  project  schedules  can  be  quantitatively  and  quali¬ 
tatively  evaluated, 

•  quantitative  or  qualitative  risk  analysis  measures 
can  be  developed  and  applied  to  evaluate  degrees  of 
project  concurrency,-  and 

•  the  Project  Manager  can  himself  make  meaningful  deci¬ 
sions  regarding  shortening  the  project  acquisition 
cycle  using  a  structured  checklist  methodology. 

Given  the  TLH,  the  PM  must  be  able  to  intelligently  apply  avail¬ 
able  analytical  techniques  to  his  project  in  order  to  make  con¬ 
currency  decisions. 

C .  DESCRIPTION  OF  ANALYTICAL  PROCESS 

The  following  is  a  brief  description  of  the  analytical 
process  represented  by  the  steps  listed  in  Exhibit  IV-3. 


IV- 8 


Step 


Step 


S  tep 


Step 


S  tep 


Step 


Step 


1.  Construct  Baseline  Schedule 

1.1  Develop  Project  Schedule  Philosophy 

1.2  Construct  Baseline  Networks 

1.3  Identify  Potential  Concurrency  Options 

1.4  Develop  Structure  of  Risk  Evaluation  Checklists 

2.  Evaluate  Funding  and  Schedule  Constraints 

2.1  Determine  Significance  of  Constraints 

2.2  Determine  Scope  of  Concurrency 

2.3  Relate  Constraints  to  Concurrency  Options 

3.  Determine  Motivation  of  Concurrency:  Schedule 

Protection  or  Schedule  Compression 

3.1  Determine  Extent  of  Internal  Program  Limitations 

3.2  Refine  Baseline  Schedule  Estimates 

3.3  Reevaluate  Preceeding  Decisions 

3.4  Develop  Initial  Set  of  Risk  Evaluation  Checklists 

4.  Determine  Degree  of  Acceptable  Cost  Risk/Schedule  Risk 

4.1  Develop  Final  Baseline  Resource  and  Schedule 

Estimates 

4.2  Determine  Acceptable  Degree  of  Concurency 

4.3  Determine  Acceptable  Degree  Risk 

4.4  Review  Remaining  Concurrency  Options 

5.  Develop  Alternative  Schedules 

5.1  Select  Constrained  Concurrency  Options  to  be 

Used  in  Developing  Alternatives 

5.2  Group  Concurrency  Options  for  Development  of 

Alternatives 

5.3  Generate  Alternative  Schedules 

5.4  Determine  Critical  Path  for  Each  Alternative 

6.  Evaluate  Risk  for  Each  Alternative 

6.1  Finalize  Evaluation  Checklists 

6.2  Apply  Checklists  to  Detailed  Schedule  and  Subschedules 

6.3  Score  Each  Alternative  Based  on  Cost  and  Schedule 

Risk  and  Response  to  Constraints 

6.4  Aggregate  Data  to  Decision  Making  Level  of  Detail 

7 .  Select  New  Schedule 

7.1  Review  and  Revise  Decision-Making  Criteria 

7.2  Review  and  Revise  Proposed  Schedule-Monitoring 

Techniques 

7.3  Analyze  Results  of  Risk  Analysis  of  Alternatives 

7.4  Apply  Decision-Making  Criteria  to  Viable  Alterna¬ 

tives 

7.5  Select  Alternative 

7.6  Revise  Existing  Schedule 


Exhibit  IV-3 .  STEPS  IN  CONCURRENCY  ANALYSIS  MODEL 
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1. 


Step  1:  Construct  Baseline  Schedule 


Purpose:  Construct  foundation  for  making  decisions  on 

program  schedules  by  performing  initial  analysis. 

Approach: 

1.1  Develop  Project  Schedule  Philosophy  (PSP) 

1.2  Construct  Baseline  Network 

1.3  Identify  Potential  Concurrency  Options 

1.4  Develop  Structure  of  Risk  Evaluation  Checklists 

The  first  step  in  addressing  the  problem  of  concur¬ 
rency  is  to  identify  the  specific  characteristics  of  the  pro¬ 
ject  which  must  be  identified  in  order  to  make  decisions  on 
adjustments  to  the  schedule.  Developing  the  project  schedule 
philosophy  involves  construction  of  the  policy  and  procedures 
or  rules  for  organizing  the  analysis,  and  construction  of  the 
criteria  for  making  scheduling  adjustment  decisions.  It  also 
includes  determination  of  the  level  of  specificity  of  the  on¬ 
going  analysis,  a  reevaluation  schedule  for  the  project  schedule 
throughout  the  acquisition,  and  a  description  of  basic  informa¬ 
tion  requirements  necessary  for  the  analysis.  This  philosophy 
is  subject  to  refinement,  as  is  the  schedule. 

After  developing  the  basic  rules  for  considering  the 
project  schedule,  the  next  substep  is  the  actual  identification 
of  the  activities  and  events  to  be  scheduled,  the  development 
of  projected  values  for  each;  the  identification  of  the  tasks 
and  subtasks  which  compose  each  activity;  and,  finally,  the 
arranging  of  this  information  in  a  set  of  networks,  reflecting 
various  levels  of  detail. 

The  third  substep  in  constructing  the  schedule  foun¬ 
dation  is  the  identification  of  concurrency  options.  Not  all 
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of  the  activities  and  events  in  a  project  schedule  can  be  con¬ 
currently  scheduled.  Therefore,  it  is  vital  to  identify  for 
each  schedule  (the  initial  as  well  as  subsequent  revisions) 
those  activities  and  events  which  can  not  be  reordered  or  adjusted. 
Although  initially  identified  when  the  program  schedule  is 
constructed,  the  concurrency  options  must  be  reevaluated  as 
portions  of  the  schedule  are  completed. 

The  final  substep  in  the  initial  organization  of  the 
analysis  is  the  development  of  the  basic  structure  of  the  risk 
evaluation  checklists.  These  checklists  will  be  used  in  Step  6 
to  evaluate  the  alternatives. 

2.  Step  2:  Evaluate  Funding  and  Schedule  Constraints 

Purpose:  To  determine  the  potential  scope  of  the 

concurrency  requirements,  based  on  speci¬ 
fic  funding  and  schedule  constraints. 

Approach: 

2.1  Determine  Significance  of  Constraints 

2.2  Determine  Scope  of  Concurrency 

2.3  Relate  Constraints  to  Concurrency  Options 

In  this  step  the  actual  analysis  of  concurrency  poten¬ 
tials  is  begun.  The  first  step  primarily  concerns  the  develop¬ 
ment  and  organization  of  information  in  a  manner  useful  to  fur¬ 
ther  analysis.  This  second  step,  evaluation  of  constraints,  in¬ 
volves  the  further  refinement  of  direction  through  a  three-step 
process . 

A  basic  assumption  underlying  this  analytical  process 
is  that  schedules  should  and  need  to  be  re— evaluated  because 
they  incorporate  an  approach  which  may  no  longer  be  appropriate. 
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Schedule  inappropriateness  may  be  due  to  a  variety  of  reasons 
(more  specifically  considered  in  Step  3).  However,  it  can  be 
translated  into  constraints  which  reflect  changes  in  resource 
requirements  or  demands.  These  constraints  may  be  due  to  cir¬ 
cumstances  within  the  program  or  outside  of  it.  They  may  take 
the  form  of  restrictions  on: 

•  the  amount  of  time  remaining  to  accomplish  an  ac¬ 
tivity  in  any  of  the  schedule  levels, 

•  the  projected  cost  allowed  to  complete  development, 

•  availability  of  organizations  to  perform  the  work, 
or 

•  the  projected  level  of  risk. 

The  characteristics  of  the  constraints  will,  in 
turn,  influence  the  potential  scope  of  the  concurrency.  The 
scope  relates  to  how  extensive  the  concurrency  may  be,  span- 
ning  phases,  functions,  task  areas,  activities  or  organiza¬ 
tions.  Less  significant  constraints  may  allow  for  restricting 
the  scope  of  the  concurrency  to  a  few  activities  at  the  sub¬ 
schedule  level.  The  more  significant  the  constraints,  in  terms 
of  total  project  resources,  the  more  extensive  the  scope  of  the 
concurrency.  The  scope  is  tentatively  determined  in  this  sub¬ 
step  and  refined,  if  necessary,  as  the  analysis  progresses. 

The  final  substep  in  Step  2  involves  relating  the 
constraints  to  the  concurrency  options  (identified  in  the  first 
step)  within  the  tentative  scope  of  the  concurrency  determined 
above.  Many  of  the  original  concurrency  options  previously 
identified  will  be  eliminated,  since  they  are  outside  the 
scope  of  the  projected  concurrency  requirements. 
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3. 


Step  3:  Determine  Motivation  for  Concurrency;  Sche¬ 

dule  Protection  or  Schedule  Compressio n 

Purpose:  Determine  the  amount  of  flexibility  and 

limitations  existing  within  the  project 
relating  to  alternatives  open  to  the  PM. 

Approach: 

3.1  Determine  extent  of  internal  project  limitations 

3.2  Refine  schedule  uncertainty  and  dependency  esti¬ 
mates 

3.3  Reevaluate  previous  decisions 

3.4  Develop  initial  set  of  risk  evaluation  check¬ 
lists. 

This  step  is  iteratively  related  to  the  preceeding 
step.  In  this  step  peculiar  characteristics  and  conditions 
within  the  project  are  considered.  Particular  consideration 
is  given  to  how  they  may  influence  or  further  constrain  the 
potential  options  for  developing  alternative  schedules.  There 
are  four  substeps  in  this  part  of  the  analysis.  The  first 
three  substeps  are  performed  and,  if  necessary  as  a  result  of 
these  analyses,  the  decisions  made  in  Steps  1  and  2  are  revised 
to  take  into  account  these  additional  constraints. 

The  first  substep  is  directed  toward  identifying 
specific  constraints  which  are  known  to  exist  within  the  pro¬ 
ject.  Some  of  these  constraints  may  prohibit  rescheduling  or 
reordering  of  activities  and  events  which  would  otherwise  be 
viable  concurrency  options.  There  are  a  variety  of  conditions 
which  could  produce  this  effect  including  already  slipped  sche¬ 
dules,  previously  completed  activities,  or  activities  already 
in  progress  which  cannot  be  redirected  or  rescheduled.  This 
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analysis  will  reveal  the  general  orientation  of  the  planning  toward 
schedule  protection  or  schedule  compression. 

In  the  second  substep  the  preliminary  estimates  on  the 
degree  of  uncertainty  and  the  dependency  of  activities  and  events 
are  reevaluated  and  refined,  if  necessary,  to  reflect  the  addi¬ 
tional  understanding  of  the  program  constraints.  Related  to 
this  is  the  third  substep  in  which  previously  made  decisions 
on  concurrency  options  and  the  checklist  structure  are  reeval¬ 
uated  and  modified,  if  necessary.  Finally,  an  initial  set  of 
checklists  is  developed  as  a  result  of  this  analysis.  These 
checklists  are  tailored  to  address  the  cost  risk  and  schedule 

risk  associated  with  the  options  used  to  generate  the  alterna¬ 
tives. 


Step  4;  Determine  Degree  of  Acceptable  Cost  Risk/ 
Schedule  Risk 


Purpose:  Finalize  draft  decision-making  criteria 

and  parameters  for  selecting  alternate 
schedules . 


Approach : 

4.1  Develop  final  baseline  resource  and  schedule 
estimates 

4.2  Determine  acceptable  degree  of  concurrency 

4.3  Determine  acceptable  degree  of  risk 

4.4  Review  remaining  concurrency  options 

In  this  step  the  bases  for  developing  the  schedule 
alternatives  are  further  refined  and  additional  detail  is  de¬ 
veloped.  in  the  first  substep  the  estimated  resource  require 
ments  for  accomplishing  the  remainder  of  the  program  schedule 
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are  reviewed  and  final  modifications  are  made.  These  esti¬ 
mates  are  for  the  cost,  time  and  manloading  required  for  each 
activity  and  event  in  the  detailed  schedule. 

Based  on  these  estimates,  the  degree  of  concurrency 
deemed  to  be  acceptable  is  determined  in  the  second  substep. 

The  degree  of  concurrency  is  based  on  the  amount  of  overlap 
a  dependent  or  successor  activity  has  with  its  predecessor 
activities The  degree  of  concurrency  acceptable  to  the  PM 
will  influence  the  amount  of  risk  associated  with  a  particular 
concurrency  option.  In  determining  the  acceptable  degree  of 
concurrency  the  PM  can  decide  an  overall  amount  for  the  program, 
such  as  "no  more  than  10%",  as  well  as  acceptable  amounts  for 
each  concurrency  option,  based  on  the  perceived  risks  associated 
with  each. 

In  addition  to  determining  the  acceptable  degree  of 
concurrency  or  amount  of  overlap  among  activities,  it  is  also 
necessary  to  determine  the  limits  of  the  risks  the  PM  is  willing 
to  tolerate  in  shortening  the  acquisition  cycle.  Of  particular 
interest  are  cost  risk  and  schedule  risk,  and  the  relationship 
between  the  two.  In  this  substep  the  PM  makes  a  preliminary 
determination  of  the  limits  of  risk  and  the  circumstances  under 
which  additional  risk  will  be  undertaken. 


11/  An  operational  definition  of  degree  of  concurrency  is  given 
and  illustrated  in  Section  V. 
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The  last  substep  is  the  final  review  of  the  remaining 
concurrency  options.  Given  the  preceeding  analysis,  it  is  pos¬ 
sible  that  some  of  the  initial  concurrency  options  may  be  elimi¬ 
nated  or  further  constrained.  It  is  important  to  determine  that 
before  proceeding  further  in  the  development  of  alternative  sche¬ 
dules,  since  those  constrained  options  form  the  basis  for  con¬ 
structing  the  alternatives. 

5 .  Step  5:  Develop  Alternative  Schedules 

Purpose:  Translate  sets  of  concurrency  options  into 

actual  scheduling  alternatives  capable  of 
•  being  evaluated  in  terms  of  cost  and  sche¬ 

dule  risk. 

Approach : 

5.1  Identify  constrained  concurrency  options  to  be 
used  in  developing  alternatives 

5.2  Group  combinations  of  options  for  each  alterna¬ 
tive 

5.3  Generate  Alternative  Schedules 

5.4  Determine  Critical  Path  for  each  alternative. 

In  this  step  the  actual  alternative  schedule  or  revi¬ 
sions  to  the  baseline  schedule  are  developed  and  prepared  for 
further  analysis.  In  order  to  do  this  the  first  substep  involves 
determining  which  of  the  remaining  concurrency  options  will  be 
used  as  the  basis  for  generating  alternatives.  It  is  conceivable 
that  not  all  of  the  options  will  be  applicable  and  an  effort 
should  be  made  to  identify  those  that  are  not.  The  potentially 
large  resources  required  to  generate  alternate  schedules  make 
that  identification  worthwhile. 

Having  identified  which  options  will  be  used,  the  next 
substep  involves  arraying  the  options  in  alternative  groupings. 
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It  is  possible  to  generate  a  variety  of  alternatives  by  varying 
the  combination  of  concurrency  options  and  the  projected  values 
and  schedule  for  each.  It  is  at  this  point  that  the  PM  has  the 
greatest  opportunity  to  be  innovative,  examining  the  specific 
needs  of  each  option  and  determining  the  minimum  requirements 
to  begin  each  activity.  These  innovative  approaches  are  con¬ 
sidered  in  the  context  of  the  acceptable  amount  or  degree  of 
concurrency  and  risk,  determined  in  Step  4. 

Having  developed  the  base  for  each  alternative,  the 
actual  alternative  schedules  can  now  be  generated.  As  part  of 
this  process  it  is  worthwhile  to  review  the  preceeding  analysis 
to  insure  that  all  of  the  internal  and  external  constraints, 
as  well  as  previously  developed  direction,  are  accounted  for  in 
the  alternative  schedules. 

The  final  substep  in  this  portion  of  the  process  is 
the  determination  of  the  critical  path  in  each  of  the  alter¬ 
natives.  It  is  possible  at  this  point  that  some  of  the  alter¬ 
natives  could  be  eliminated  from  further  consideration  due  to 
the  construction  of  the  critical  path. 

6.  Step  6:  Evaluate  Risk  for  Each  Alternative 

Purpose:  Analyze  alternative  schedules  as  approaches 

for  responding  to  constraints. 

Approach: 

6.1  Finalize  risk  evaluation  checklists 

6.2  Apply  checklists  to  detailed  schedules 

6.3  Score  each  alternative  based  on  cost  and 
schedule  risk,  and  response  to  constraints 

6.4  Aggregate  data  to  decision-making  level  of 
detail . 
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In  this  step  the  alternative  schedules  generated  in 
Step  5  are  evaluated  to  determine  their  appropriateness  as  ap¬ 
proaches  to  dealing  with  the  new  constraints.  The  major  mech¬ 
anism  for  doing  this  is  a  set  of  evaluation  checklists,  tai¬ 
lored  to  particular  phases,  functions,  task  areas  and  activi¬ 
ties  of  interest  in  the  particular  analysis.  The  first  sub¬ 
step  in  this  evaluation  is  finalizing  the  checklists  initial¬ 
ly  developed  in  Step  3.  The  final  version  of  the  checklists 
should  be  tailored  to  address  the  particular  activities  and 
events  which  have  been  manipulated  in  the  alternative  sche¬ 
dule.  They  must  be  designed  to  produce  a  risk  value,  e.g., 

High,  Moderate,  Low,  for  each  consideration.  Since  the  sche¬ 
dules  are  generated  at  multiple  levels  of  detail,  the  check¬ 
lists  must  address  those  same  levels.  The  checklists  are  now 
reviewed  to  ensure  their  consistency  with  the  decision-making 
criteria  originally  developed  in  the  PSP  (Step  1). 

After  finalizing  the  evaluation  checklists,  they  will 
be  used  to  review  each  concurrency  alternative.  These  check¬ 
lists  will  be  structured  to  address  the  activities  and  events 
rescheduled  in  the  alternatives.  However,  in  applying  them, 
the  values  and  degree  of  concurrency  and  risk  determined  for 
each  option  or  group  of  activities  must  also  be  considered. 

In  the  third  substep  the  projected  cost  and  schedule 
risks  associated  with  each  alternative  are  quantified.  The 
result  of  this  analysis  is  a  ranking  according  to  cost  and  sche¬ 
dule  risk  of  the  alternative  schedules.  This  ranking  reflects 
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the  results  of  applying  the  checklists  to  each  alternative,  in 


light  of 

• 

the  following  considerations: 

degree  of  concurrency, 

• 

• 

total  risk  calculated  and  the  peak  risk  estimated, 

amount  of  uncertainty  associated  with  the  resource 
and  schedule  estimates, 

• 

dependency  relationship  among  activities  and  events. 

• 

• 

overall  influence  of  activity  in  program  schedule 
and  cost, 

stage  of  system  technology  development,  and 

• 

perceived  scope  of  impact  of  decision/consequences 
of  failure  of  schedule  or  cost  projections. 

Specific  attention  must  be  given  to  determining  the  risks 
of  exceeding  the: 


• 

total  costs  if  the  concurrently  scheduled  activity 
fails  to  succeed, 

• 

total  schedule  if  the  concurrently  scheduled  activity 
fails  to  succeed,  and 

• 

projected  activity  cost  or  schedule  estimate. 

The 

final  substep  in  the  risk  evaluation  portion  of  the 

analysis 

involves  aggregating  the  risk  values  to  the  predeter- 

mined  decision-making  level  of  detail.  Depending  on  the  cir¬ 
cumstances  this  may  occur  at  the  Summary,  Detailed  or  Sub- 


schedule 

level . 

7. 

Step  7 :  Select  New  Schedule 

Purpose:  To  make  decisions  on  schedule  revisions 

based  on  analyzing  risks  associated  with 
the  alternatives. 
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Approach: 

7.1  Review  and  revise  decision-making  criteria  in 
PSP 

7.2  Review  and  revise  techniques  for  monitoring  re¬ 
vised  schedule  and  potential  alternatives 

7.3  Analyze  results  of  risk  analysis  of  alternatives 

7.4  Apply  decision-making  criteria  to  viable  alter¬ 
natives 

7.5  Select  alternative 

7.6  Revise  existing  schedule. 

The  final  step  in  this  analysis  involves  making  deci¬ 
sions  on  the  alternative  schedules.  In  the  preceeding  steps 
preliminary  decisions  would  have  been  made  on  how  to  decide 
which  of  the  alternatives  will  be  selected  and  how  to  evaluate 
the  effectiveness  of  the  revised  schedule.  The  first  substep 
in  this  final  part  of  the  analysis  is  to  review  and  revise,  if 
necessary,  the  decision  criteria  contained  in  the  PSP.  In 
the  process  of  identifying  and  reviewing  the  concurrency  op¬ 
tions,  and  developing  and  evaluating  the  alternative  schedules, 
it  is  quite  possible  that  additional  imperatives  contributing 
to  the  decision-making  process  will  be  identified.  The  criteria 
should  be  modified  to  incorporate  those  additional  considerations. 

In  addition  to  reviewing  the  decision-making  criteria 
it  is,  at  this  point,  also  useful  to  review  the  originally  pro¬ 
posed  techniques  for  monitoring  the  revised  schedule  and  the 
potential  alternatives.  In  the  set  of  alternative  schedules 
some  will  be  eliminated  for  future  consideration  simply  by 
the  choice  of  a  particular  alternative.  However,  some 
alternatives  may  not  be  totally  eliminated  as  possibilities 
since  their  divergence  from  the  revised  schedule  occurs  later 
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in  the  project.  These  alternatives  should  be  monitored  as 
the  schedule  progresses  to  allow  their  maintenance  as  sche¬ 
duling  options. 

The  third  substep  involves  analysis  of  the  results 
of  the  risk  analyses,  performed  in  Step  6.  The  risk  values 
developed  for  each  alternative  are  arrayed  on  a  graph  illus¬ 
trating  their  comparative  cost  and  schedule  risk  values. 
Additional  illustrations  such  as  cost  and  schedule  contours 
are  also  developed  as  part  of  this  substep. 

The  fourth  substep  involves  evaluating  each  of  the 
risk-assessed  alternatives  in  terms  of  the  decision-making 
criteria.  If  constructed  adequately,  these  criteria  represent 
the  significant  points  of  concern  and  priorities  of  the  PM. 
Each  alternative  is  given  a  ranking  based  on  the  risk  assess¬ 
ment  and  application  of  the  decision-making  criteria. 

The  fifth  substep  is  the  actual  selection  of  the 
alternative  or  revised  schedule,  and  the  secondary  alterna¬ 
tives  which  will  be  monitored. 

The  final  substep  in  this  process  is  the  initiation 
of  the  revised  schedule  and  incorporation  of  it  into  the 
project  plan. 
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V.  DISCUSSION  OF  POTENTIAL  APPLICATIONS 


The  MCR  concurrency  analysis  methodology  has  been 
designed  for  analyzing  a  wide  range  of  constraints.  It  is 
not  inherently  limited  to  analyzing  major,  "program-shaking" 
decreases  in  acquisition-cycle  time  or  cost.  In  addition, 
the  methodology  has  not  been  tailored  to  a  particular  type  of 
system  but  rather  is  flexible  enough  to  be  used  with  any  pro¬ 
gram  which  has  a  schedule.  It  has  been  designed  to  gradually 
reduce  the  variety  of  alternatives  the  PM  must  consider  through 
a  multi-step  process  of  refining  scheduling  requirements,  con¬ 
straints  and  decision-making  criteria.  This  allows  the  consi¬ 
deration  of  only  those  alternative  schedules  which  are  not 
only  feasible  but  practical  as  well.  Finally,  the  alterna¬ 
tives  are  evaluated  using  methods  tailored  to  the  particular 
characteristics  of  the  project. 

In  the  previous  section  the  basic  MCR  methodology  and  the 
rationale  behind  it  were  described.  In  this  section  the 
actual  circumstances  in  which  the  PM  must  apply  the  method¬ 
ology  are  discussed. 

A.  PLANNING  NEEDS  AND  CONSIDERATIONS 

One  of  the  findings  of  MCR's  research  is  that  PMs  have  cer¬ 
tain  concurrency-related  needs  which  must  be  recognized  and 
responded  to.  These  needs  are  the  ability  to: 

•  define  the  amount  or  degree  or  concurrency  deemed 
desirable  for  a  project; 
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•  determine  the  activities  which  can  be  (or  are 
amenable  to  being)  concurrently  scheduled; 

•  evaluate  the  cost-risk  impact  on  the  project  goals, 
thresholds  and  requirements  of  concurrently  sche¬ 
duling  activities;  and 

•  justify  these  decisions  to  the  Navy  hierarchy  and 
OSD. 

In  order  to  fulfill  these  needs  the  PM  must  work  within 
the  peculiar  conditions  of  the  project.  There  are  several 
kinds  of  considerations  with  which  the  PM  must  deal;  the  major 
ones  are: 

•  the  organization  of  the  Project  Management  Office 
( PMO ) 

•  the  activities  and  events  which  must  be  scheduled, 
and 

•  the  allocation  or  distribution  of  this  work  among: 

-  functional  analytical  groups  within  the  Navy, 

contractors,  and 
the  PMO  itself. 

Each  project  can  be  organized  differently,  distributing  the 
various  tasks  which  must  be  accomplished  among  groups  as  de¬ 
termined  by  the  PM  and  the  particular  characteristics  of  the 
project.  However,  certain  basic  functions  must  be  performed 
simply  due  to  the  nature  of  a  design  effort,  while  others  are 
dictated  by  the  nature  of  the  system  being  acquired. 

Initial  emphasis  has  been  placed  on  the  ship  acquisition 
process.  Although  the  methods  used  by  the  Navy  to  design  and 
acquire  major  surface  ships  have  undergone  periodic  revision, 
there  is  a  fairly  standard  practice  in  general  use  at  any  point 
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in  time.  The  current  practice,  specifically  the  PMS/SHAPM  (pro¬ 
ject  manager,  ships  acquisition  project  manager)  organization 
and  the  activities  and  events  generally  identified  with  the 
TLR/TLS  (top  level  requirements/top  level  specifications)  de— 
sign  process  will  be  used  as  the  basis  for  this  discussion  of 
planning  considerations.  This  does  not  mean,  however,  that 
all  ship  acquisition  projects  will  be  organized  in  this  manner 
or  that  all  projects  will  require  this  same  set  of  activities 
and  events.  Rather,  they  are  used  here  as  specific  examples. 

•  1 .  Organization  of  the  Project  Management  Office 

Project  Management  Offices  (PMOs)  are  generally  de¬ 
signed  to  provide  a  core  of  analytical,  technical  and  admin¬ 
istrative  personnel  responsible  for  the  accomplishment  of 
the  activities  required  to  design  and  acquire  a  particular 
system.  The  actual  size  and  composition  of  the  project  of¬ 
fice  is  determined  by,  among  other  things: 

•  the  particular  system,  or  for  our  purposes,  the 
particular  ship  project, 

•  the  schedule  and  cost  constraints  and  performance 
requirements  of  the  project,  and 

•  the  management  orientation  of  the  SHAPM  and  his 
staff . 

As  generally  organized  now  there  are  several  different 
groups  within  the  Navy  which  can  be  involved  in  the  design  and 
development  of  a  Navy  surface  ship.  Some  of  these  organizations 
respond  to  the  direction  of  the  project  manager,  or  SHAPM,  while 
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others  are  responded  to  by,  or  provide  direction  to,  the  SHAPM.  Ex¬ 


hibit  V— 1  shows  the  general  relationship  of  the  PM/SHAPM  to  these 
various  groups.  In  project  schedule  planning,  emphasis  is  placed 
on  the  activities  to  be  performed  under  the  direction  of  the 
SHAPM. 

In  the  designing  of  ships,  the  PM,  or  SHAPM,  must  work 
closely  with  the  Ship  Design  Manager  (SDM)  who  is  responsible 
for  overseeing  the  technical  design  of  the  ship.  This  involves 
the  integration  of  the  ship  hull,  mechanical  and  electrical 
(HM&E)  systems,  with  the  Combat  System  Design  and  the  Support 
System  Design.  Exhibits  V-2,  V-3,  V-4  and  V-5  show  the  basic 
relationships  among  these  groups  and  the  basic  organization  of 
the  SHAPM,  ship  design  team  and  combat  system  engineering  team, 
respectively.  The  actual  responsibilities  of  these  groups  will 
vary  depending  on  the  project  and  the  development  phase.  In 
addition  to  these  groups  there  are,  within  the  Navy  Systems  Com¬ 
mands  various  functional  groups  specializing  in  providing  parti¬ 
cular  types  of  project  support,  e.g.,  logistics  analysis  and 
contract  support.  While  providing  support  to  the  specific  pro¬ 
ject  office  (as  well  as  several  others),  these  groups  may  not 
be  under  the  direct  control  of  the  SHAPM. 

Part  of  the  Project  Manager's  requirement  in  planning 
and  reviewing  the  project  schedule  must  involve  the  interrelation¬ 
ships  among  these  groups  and  the  activities  they  are  performing 
on  the  project. 
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Exhibit  V-l.  ORGANIZATIONS  RESPONDING  TO  PM  DIRECTION 
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Exhibit  V-2.  PROGRAM  MANAGEMENT  ORGANIZATION 
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Exhibit  V-3.  TYPICAL  SHAPM  ORGANIZATION 
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Exhibit  V-4 .  SHIP  DESIGN  ORGANIZATION 
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Exhibit  V-5 .  COMBAT  SYSTEM  ENGINEERING  ORGANIZATION 


2. 


Project  Activities  and  Events  to  be  Scheduled 


The  design  and  acquisition  of  a  ship  system  is  accom¬ 
plished  through  a  sequence  of  activities  and  events.  The  ac¬ 
tivities  and  events  are  planned  to  be  performed  in  an  orderly 
fashion,  moving  through  a  logical  progression  culminating  ini¬ 
tially  in  the  construction  and  testing  of  a  lead  ship,  and  ul¬ 
timately  in  the  completion  of  all  of  the  ships  of  the  class. 

Project  schedules  are  the  means  by  which  these  activities  and 
events  are  planned  and  progress  is  monitored.  The  basic  components 
of  the  project  schedule,  identified  in  Section  IV,  are  (in  terms 
of  ship  acquisition  projects): 

•  Phases  -  design  and  acquisition  phases  such  as  Feasi¬ 

bility  Studies,  Preliminary  Design,  and  Detail 
Design; 

•  Functions  -  major  categories  of  work  performed  by,  or 

under  the  direction  of  the  SHAPM ,  such  as 
Technical  Management,  Financial  Manage¬ 
ment,  and  Integrated  Logistics  Support  (ILS) 
Management  ,- 

•  Task  Areas  -  subtasks  of  functional  work  such  as 

hardware  design,  software  design,  test 
and  evaluation,  etc.,  under  Technical 
Management ; 

•  Events  -  points  beginning  or  ending  an  activity  such 

as  issuance  of  a  ship  acquisition  plan 
(SHAP)  outline;  fixed  decision  points  such 
as  DSARC  milestones,  or  prescribed  document 
reviews  and  updates,  such  as  SHAP  and  Decision 
Concept  Paper  ( DCP )  updates; 

•  Activities  -  efforts  involved  in  preparing  for  a 

particular  event,  such  as  reviewing  the 
SHAP,  or  in  response  to  an  initiating 
event,  such  as  development  of  the  pre¬ 
liminary  TLR  initiates  preliminary  de¬ 
sign  efforts;  and 
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•  Organizations  -  groups  responsible  for  performing 

the  activities,  such  as  the  SHAPM , 
NAVSEA  32D ,  NAVSEA  61,  etc. 

Schedules  are  developed  for  each  group  having  respon¬ 
sibilities  in  the  ship  design  and  acquisition  process.  For 
this  analysis  three  layers  of  scheduling  detail  have  been  iden¬ 
tified  : 

•  Summary  schedules,  displaying  the  major  events  in  the 
project  for  each  function  and  task  area.  Exhibit 
V-6  is  an  example  of  the  summary  schedule  level  of 
detail . 

•  Detailed  schedules,  showing  an  exploded  view  of  task 

•  area,  with  additional  detail  on  the  specific  activi¬ 

ties  occurring  during  the  period  of  time,  with  indi¬ 
cations  of  inputs  from  and  outputs  to  other  task 
areas . 

•  Sub-schedules,  showing  a  still  lower  level  of  detail, 
giving  an  exploded  view  of  each  activity  within  each 
task  area,  with  dependency  relationships  indicated. 

These  schedules  form  an  interlocking  hierarchy  of 
detail  and  form  the  basis  for  developing  the  networks  on  which 
the  concurrency  analysis  is  based.  As  mentioned  previously, 
these  schedules  and  their  related  networks  are  developed  for 
the  activities  being  performed  by  the  various  groups  involved 
in  the  ship  design  and  acquisition  process.  Exhibits  V-7 ,  V-8 , 
and  V-9  illustrate  examples  of  the  design  work  breakdown  struc¬ 
tures  related  to  the  development  of  surface  combatants.  Schedules 
would  be  developed  for  the  activities  required  for  and  related 
to  each  of  the  elements  in  these  structures. 
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Exhibit  V-6.  EXAMPLE  OF  SUMMARY  SCHEDULE 
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Exhibit  V-7 .  SHIP  DESIGN  WORK  BREAKDOWN  STRUCTURE 
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Exhibit  V-8.  COMBAT  SYSTEM  BREAKDOWN  STRUCTURE 
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Exhibit  V-9.  SUPPORT  SYSTEMS  WORK  BREAKDOWN  STRUCTURE 


3 .  Distribution  of  Project  Design  Responsibilities 

The  final  consideration  of  particular  interest  to 
the  PM/SHAPM  is  the  assignment  of  the  various  design  and  ac¬ 
quisition  responsibilities.  In  this  discussion,  as  well  as 
the  previous  discussions,  responsibility  for  performing  this 
analysis  has  been  identified  with  the  PM  or  SHAPM ,  in  the 
case  of  ship  acquisition  projects.  In  actual  practice  this 
responsibility  may  be  delegated  to  other  members  of  the  de¬ 
sign  or  planning  team  such  as  the  Ship  Design  Manager.  All 
groups  involved  in  the  design  effort  will,  at  the  very  least, 
have  to  provide  information  in  order  to  perform  this  analysis. 

As  can  be  seen  from  the  preceeding  discussions, 
project  scheduling  involves  the  coordination  of  a  complex 
variety  of  groups  and  activities.  Contributing  to  the  com¬ 
plexity  of  this  problem  may  be  the  need  to  obtain  still  more 
information  from  outside  the  specific  systems  command.  For 
example,  it  has  been  noted  that 

.  .  .  ship  design  is  not  done  solely  within  NAVSEA 

through  the  Contract  Design.  The  Naval  Electronics 
Command  designs  the  interiors  of  the  communications, 
electronic  countermeasures,  and  intelligence  spaces, 
as  well  as  participating  in  the  placement  of  those 
antennas.  The  Naval  Supply  Systems  Command  designs 
the  interiors  of  all  the  galley  and  commissary  spaces. 

The  Bureau  of  Medicine  and  Surgery  designs  the  inter¬ 
iors  of  the  operating  rooms.  And  the  Naval  Air  Systems 
Command  establishes  many  standards  with  respect  to 
flight  safety,  determines  requirements  for  maintenance 
and  personnel,  and  lays  out  the  hangar  deck  on  a  CV 
to  determine  the  number  of  aircraft  that  a  proposed 
design  can  hold.  This  adds  to  the  complexity  of  the 
management  problem. 12/ 

12/  "The  Changing  Nature  of  the  U.S.  Navy  Ship  Design  Process," 
Robert  S.  Johnson,  Ship  Design  and  Integration  Directorate, 
Naval  Sea  Systems  Command,  1980. 
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Design  responsibilities  may  ultimately  be  assigned 

based  on  the  determination  of  those  which  must  be  performed 

by  certain  groups,  such  as  those  discussed  above,  and  those 

that  are  open  to  assignment  by  the  PM/SHAPM.  The  ultimate 

designation  of  responsibility  for  performing,  or  seeing  to 

the  performance,  of  an  activity  may  have  substantial  impact 

on  the  scheduling  flexibility  of  these  activities,  since  there 

may  be  a  decided  difference  in  response  capability  for  work 

performed  in-house  and  work  performed  by  independent  design 

agents.  This  has  been  a  more  recent  problem  in  ship  design: 

Today,  only  28  percent  of  the  (ship  design)-  work  is 
done  "in-house"  and  the  other  72  percent  contracted  out. 
These  percentages  do  not  truly  reflect  the  seriousness 
of  the  situation.  If  one  NAVSEC  employee  can  technically 
manage  and  review  the  work  of  four  contractor  employees, 
this  means  that  18  percent  of  the  total  work  is  technical 
management.  Thus,  only  10  percent  of  the  ship  design 
work  is  actually  "hands  on"  technical  work  in  NAVSEC  and 
most  of  that  is  ship  integration.  Hence,  today  the  actual 
engineering  of  ship  systems  is  being  done  by  design  agents 
and  other  private  technical  firms. 13/ 


B-  APPLICATION  CONSIDERATIONS 

Given  this  brief  discussion  of  the  planning  needs  and 
considerations  of  the  PM/SHAPM,  it  is  now  possible  to  discuss 
more  specific  considerations  related  to  actual  application  of 
the  concurrency  analysis  methodology. 


13/  Ibid. 
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As  mentioned  in  the  summary  of  the  background  research, 

concurrency  has  been  most  often  thought  of  as  overlapping  of 

the  full-scale  development  and  production  phases.  In  ship 

acquisitions  concurrency  has  had  a  dual  role: 

Concurrency  is  often  used  in  two  areas  of  the  acquisi¬ 
tion  process  to  minimize  the  time  required  to  acquire 
a  class  of  ships.  First,  there  may  be  concurrency  in 
the  development  of  the  detail  design  and  early  construc¬ 
tion  efforts.  Normally  it  is  expected  that  subsystems 
or  equipments  will  be  tested  and  accepted  for  fleet  use 
before  they  are  designated  for  inclusion  in  a  new  class 
of  ships.  However,  situations  may  arise  in  which  major 
improvements  are  anticipated  from  equipment  currently 
under  development.  In  those  cases,  a  decision  must  be 
made  on  whether  to  accept  the  lower  performance  avail¬ 
able  from  proven  equipment  or  to  accept  some  risk  by 
continuing  development  of  new  equipments  that  promise 
to  meet  the  projected  performance  goals  and-  completion 
schedule . 

The  second  aspect  of  concurrency  is  ordering  the  early 
follow  ships  before  the  first  ship  has  been  delivered 
and  tested.  The  decision  on  the  timing  of  the  award 
for  early  follow  ships  and  start  of  construction  of 
these  ships  should  refect  a  tradeoff  between  an  accept¬ 
able  level  of  risk  that  the  lead  ship  will  satisfy  the 
stated  requirements  and  the  desire  to  deliver  follow 
ships  as  early  as  possible  so  that  they  will  have  maxi¬ 
mum  useful  life.  It  is  because  of  the  latter  reason 
that  decisions  are  made  on  most  ship  acquisition  pro¬ 
grams  to  not  utilize  the  lead  ship  as  a  true  prototype 
for  the  remaining  ships  of  the  class.  Another  reason 
for  rejecting  the  prototype  approach  is  that  the  ship 
system  as  a  whole  generally  incorporates  hardware  which 
is  off-the-shelf,  state— of —the— art  and  therefore  does 
not  pose  the  kind  of  risk  posed  by  a  system  comprised 
for  the  most  part  of  advanced-technology  hardware. 14/ 

Decisions  on  the  use  and  placement  of  concurrency  are 

contingent  upon  several  conditions: 


1_4/  Relationship  Between  Acquisition  Strategy  and  the  Con¬ 
tract  Design  Package , "  Advanced  Marine  Enterprises,  Inc., 
Arlington,  Virginia  22202,  22  February  1977. 
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•  the  magnitude  of  the  constraint,  i.e.,  the  amount 
of  time  that  the  schedule  must  be  reduced; 

•  the  portion  of  the  schedule  affected  by  the  con¬ 
straint,  i.e.,  the  activities  remaining  to  be  ac¬ 
complished  or  which  can  be  rescheduled,  and 

•  the  opportunity  to  analyze  the  risks  and  impacts 
of  making  the  decision. 

As  envisioned  now,  this  analysis  would  be  part  of  the  overall 
effort  to  develop  and  update  the  acquisition  program  plan. 

This  would  mean  that  the  concurrency  analysis  would  be  ini¬ 
tiated  in  the  concept  development  phase  and  identified  in  the 
outline  of  the  acquisition  plan.  There  are  two  reasons  for 
advocating  early— on  concurrency  analysis: 

•  the  earlier  the  process  is  incorporated,  the  earlier 
the  alternatives  and  risks  can  be  identified  and 
monitored;  and 

•  the  initial  analysis  may  be  complex,  however,  once 
the  apparatus  for  performing  the  analysis  has  been 
developed,  subsequent  reviews  will  be  easier  to 
implement . 

Early— on  planning  also  allows  the  gathering  of  the  nec¬ 
essary  information  and  organization  of  the  schedule  to  facil¬ 
itate  the  concurrency  analysis  from  the  beginning.  This  is 
particularly  critical  due  to  the  need  to  identify  tasks  or 
activities  which  are  analytically  compatible.  The  concurrency 
analysis  rests  on  the  ability  of  the  analysts  to  determine 
how  much  of  an  activity  is  complete,  or  will  be  complete,  at 
a  given  point  in  time.  This  is  used  in  the  calculation  of 
the  degree  of  dependence  the  activity  has  on  other  activities, 
combined  with  the  degree  of  uncertainty  related  to  the  resource 
projections.  The  degree  of  uncertainty,  in  turn,  is  related  to 
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how  much  of  the  activity  has  actually  been  completed  at  the  time 
of  the  analysis,  where  the  activity  occurs  in  the  sequence,  how 
dependent  the  activity  is  on  other  activities,  and  how  sensitive 
it  is  to  exogenous  factors.  Exhibit  V-10  illustrates  the  degree 
of  technological  uncertainty  at  progressive  stages  of  the  ac¬ 
quisition  process.  A  similar  pattern  exists  in  the  accomplish¬ 
ment  of  activities  within  these  stages.  It  may,  however,  be  more 
useful  to  the  PM  to  measure  activities  not  in  terms  of  amount  of 
work  completed  but  rather  by  the  completion  of  the  amount  of  time 
allocated  for  the  task.  The  only  requirement  is  that  whatever 
measure  is  used  allows  for  a  meaningful  comparison  of  the  tasks. 

The  ultimate  goal  of  the  methodology  is  to  provide  the 
decision  maker  with  a  tool  for: 

•  identifying  activities  which  can  be  concurrently 
scheduled,  and 

•  evaluating  the  cost  and  schedule  risks  associated 
with  them. 

In  order  to  do  this  the  analysts  must  ask  a  series  of  quali¬ 
tative  questions  which  assist  in  determining  the: 

•  degree  of  activity  dependence, 

•  amount  of  acceptable  concurrency  to  be  permitted 
among  difficult  activities,  and 

•  amount  of  acceptable  cost  and  schedule  risk  con¬ 
sidered  tolerable  for  the  planned  scope  of  the 
concurrency. 

Questions  which  would  have  to  be  answered  would  be,  for 
example : 
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System  Integration 


Fabrication, 

Assembly , 
And  Testing 


System  Design 


System  Development 


Operation 
And  Support 


Full-Scale 
Development 
Fhase 


Production 

Phase 


Deployment 

Phase 


Source:  K.  E.  Brandt,  "Decision  Risk  Assessment  and  Analysis  in  the 

Weapons  System  Acquisition  Process,"  USAF  Aeronautical  Systems 
Division,  January  1974. 


Exhibit 


V-10.  THE  DEGREE  OF  TECHNOLOGICAL  UNCERTAINTY 
AT  PROGRESSIVE  STAGES  (RISK) 
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•  What  information  is  needed  to  begin  the  activity? 

•  What  are  the  sources  of  this  information? 

•  Are  they  under  the  control  of  the  PM/SHAPM? 

•  How  much  of  the  activity  has  been  completed  at  this 
time? 

•  How  much  of  the  tasks  which  provide  input  informa¬ 
tion  to  this  activity  must  be  complete  before  this 
activity  can  be  initiated? 

•  Is  the  source  activity  (the  activity  or  task  provid¬ 
ing  information),  expected  to  meet  its  schedule?  If 
not,  how  uncertain  is  this  schedule? 

The  methodology  is  designed  to  use  two  different  check¬ 
lists.  These  checklists  are  to  be  used  to: 

•  evaluate  activities  and  events  to  determine  concur¬ 
rency  options,  and 

•  evaluate  the  cost  and  schedule  risks  associated  with 
the  different  schedule  alternatives. 

In  identifying  the  concurrency  options,  activities  are 
initially  categorized  in  terms  of  those  that: 

•  can  not  be  rescheduled,  reorganized  or  reordered; 

•  might  be  possible  to  reschedule,  reorganize  or  re¬ 
order,  but  for  a  variety  of  reasons  are  less  desirable ; 
and 

•  can  be  rescheduled,  reorganized  or  reordered. 

Initial  emphasis  would  be  placed  on  the  third  category. 

Assignment  to  any  of  the  categories  is  based  on  current  under¬ 
standing  of  the  conditions  prevailing  in  the  project.  It  is, 
therefore,  possible  that  activities  previously  considered  as 
unlikely  concurrency  options  may,  after  further  consideration, 
be  re-categorized.  As  mentioned  before,  the  identification 
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of  potential  concurrency  options  is  of  substantial  importance 
since  those  options  provide  the  basis  for  generating  the  alter¬ 
native  schedules. 

The  concurrency  options  are  grouped  in  various  combina¬ 
tions  and  with  different  sets  of  constraints  in  order  to  gen¬ 
erate  different  schedules.  An  option  comprises  at  least  a 
pair  of  activities,  composed  of  an  independent  or  source  ac¬ 
tivity,  i.e.,  the  activity  which  provides  information  to  the 
dependent  activity,  and  the  dependent  activity  which  succeeds 
the  source  activity  and  would  begin  before  completion  of  the 
source  activity.  Options  may  actually  comprise  clusters  of 
activity/event  combinations,  representing  all  of  the  sub¬ 
schedule  activities  related  to  a  detailed  schedule  activity. 

The  composition  of  an  option  is  completely  dependent  upon 
the  perceived  reguirements  of  the  project.  However,  gener¬ 
ally,  dependent  activities  within  an  option  should  be: 

•  under  the  control  or  direction  of  the  PM,  and 

•  influence  the  project  cost  or  schedule  duration. 

Exhibit  V-ll  illustrates  the  basic  relationship  of  concur¬ 
rency  options  to  alternative  schedules.  A  sequence  of  activi¬ 
ties,  Tasks  A  through  F,  is  shown.  Based  on  analysis  of  the 
dependency  relationships,  the  degree  of  uncertainty  associated 
with  them,  and  the  role  of  each  task  in  the  total  sequence, 
options  are  selected.  The  options,  any  or  all  of  which  may  be 
used  in  generating  the  alternatives,  are: 
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Option 

Degree  of  Concurrencv 

A-B 

• 

B  +  5  Months/37.5% 

C-D 

• 

C  +  A  Months/66.7% 

D-E 

• 

E  +  3  Months/25.0% 

c/e-f 

• 

F  +  2  Months/33.3% 

Acceptable  Target 
Degree  of  Cost  Risk* 

10% 

30% 

5% 

20% 


Acceptable  Target 
Degree  of  Schedule  Risk* 

15% 

20% 

10% 

15% 


*  Degree  of  Risk  =  Probability  of  failure  to  meet  estimated  cost  or  schedule. 


Exhibit  v-ll. 
OPTIONS  TO 


RELATIONSHIP  OF  CONCURRENCY 
ALTERNATIVE  SCHEDULES 
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•  overlap  of  B  with  A,  A-B  option, 

•  overlap  of  C  with  D,  C-D  option, 

•  overlap  of  E  with  D,  D-E  option,  and 

•  overlap  of  F  with  both  C  and  E,  C/E-F  option. 

Having  determined  the  options,  limiting  values  must  be  de¬ 
veloped  to  use  in  generating  the  alternative  schedules.  The 
characteristics  which  are  manipulated  for  each  alternative  are: 

•  the  applicable  concurrency  options, 

•  the  related  resource  estimates  for  each  activity  on  the 
schedule  (reflecting  the  additional  constraints), 

.  •  the  maximum  acceptable  degree  of  concurrency  for  each 

option,  and 

•  the  maximum  acceptable  degree  of  cost  and  schedule  risk 
for  each  option. 

Alternatives  are  structured  taking  into  account  the  degree 
of  uncertainty  associated  with  the  initial  estimates.  Part  C  of 
Exhibit  V-ll  shows  the  alternative  generated  base  on  the  selec¬ 
tion  of  options  and  tailoring  of  values  for  the  characteristics. 

After  generating  the  various  alternatives,  it  is  necessary 
to  evaluate  the  risks  of  each  in  terms  of  cost  and  schedule. 

The  basic  tools  in  this  analysis  are  the  cost  risk  evaluation 
checklists  and  the  schedule  risk  evaluation  checklists.  They  are 
designed  to  address  the  concerns  the  decision  maker  must  keep 
in  mind  in  order  to  weigh  the  alternatives.  Exhibits  V-12  and 

are  examples  of  the  kinds  of  considerations  necessary  for  de¬ 
velopment  of  the  checklists.  Actual  checklists  would  have  to  be 
tailored  to  the  particular  application  at  hand.  The  purpose  of 
the  risk  evaluation  is  not  only  to  estimate  the  potential  risk 
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Exhibit  V-12.  COST  RISK  CONSIDERATIONS  IN  SYSTEM  DESIGN 


Is  the  activity  dependent  on  information  or  inputs  from 
outside  the  performing  organization? 

Is  the  manpower  within  the  performing  organization  subject 
to  fluctuation;  i.e.,  is  the  performing  organization  re¬ 
sponsible  for  performing  similar  activities  for  other  pro¬ 
grams  and,  therefore,  the  manpower  must  be  competed  for? 

Does  the  ability  to  compete  (or  lack  thereof)  indi¬ 
cate  relative  value  or  importance  and,  therefore,  can 

the  program  expect  to  have  lower  priority  in  other 
areas? 

How  much  of  the  input  information  is  needed  in  order  to 
begin  the  dependent  activity? 

Is  development  of  the  input  information  from  outside  of 
the  performing  organization  on  time?  Do  they  expect  it 
to  stay  on  time? 

What  other  parts  of  the  schedule  are  dependent  on  this 
information?  Information  from  this  group? 

Has  allowance  for  schedule  slippage  been  incorporated  in 
the  time  estimate? 

Have  additional  quality  assurance  measures  been  identified 
in  order  to  reduce  potential  risks  associated  with  con¬ 
currently  scheduling  the  activity? 


Exhibit  V-13.  SCHEDULE  RISK  CONSIDERATIONS 


associated  with  each  alternative,  but  also  to  rank  the  appro¬ 
priateness  of  each  alternative.  It  is  possible  to  generate  alter¬ 
natives  with  mutually  conflicting  cost  and  schedule  constraints 
or  risks. 

Exhibit  V-14  illustrates  the  results  of  evaluating  the 
alternatives  generated  in  the  example  given  in  Exhibit  IV-11. 

In  addition  to  calculating  the  total  amount  of  time  saved,  the 
specific  cost  and  schedule  tasks  must  be  calculated  for  each 
option  as  well  as  the  total  for  the  alternative.  As  part  of 
this  analysis,  it  is  also  important  to  determine  the  "peak" 
risk,  i.e.,  the  options  with  the  highest  potential  cost  and 
schedule  risk.  This  is  particularly  important  if  the  potential 
risk  is  higher,  or  related  to  a  different  option  than  the  origi¬ 
nal  "target"  degree  of  risk,  as  illustrated  in  this  example. 

The  effectiveness  of  the  application  of  the  concurrency 
analysis  methodology  can  be  quantified  once  this  analysis  has 
been  made. 

Suppose  that  the  portion  of  interest  in  the  schedule  for  a 
particular  project  cannot  be  completed  in  less  than  Tq  units  of 
time,  say  months.  Suppose  further  that  the  baseline  schedule  for 
that  portion  of  the  project  has  a  duration  of  TD  months.  If  a 

D 

concurrent  schedule  will  complete  the  project  in  months,  then 
one  measure  of  the  effectiveness  of  the  concurrency  accomplished 
by  the  latter  schedule  is 
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Exhibit  V-14 .  EVALUATION  OF  ALTERNATIVE  SCHEDULE 


Clearly,  this  is  a  relative  measure  since,  for  any  given 
project,  the  potential  effectiveness  of  applying  concurrency  will 
change  as  the  completion  time  for  the  baseline  schedule  changes 
and  the  schedule  progresses.  Simply  stated,  this  measure  of  the 
degree  of  concurrency  gives  the  percent  of  time  that  can  be  saved 
in  the  baseline  schedule  that  is  actually  saved  by  implementing 
the  concurrent  schedule. 

Generally  speaking,  projects  are  not  completed  in  the  shortest 
possible  time,  e.g.,  in  Tq  years.  That  is  because  of  budget  limi¬ 
tations  or  the  risks,  technological  and  otherwise,  that  are  intro¬ 
duced  as  one  tries  to  shorten  the  acquisition  time.  Thus,  the  degree 
of  concurrency  sought,  Dc ,  must  be  balanced  against  the  risk  of 
successful  program  completion  within  a  specified  budget  and  time, 
and  producing  a  specified  level  of  product  performance. 

In  Exhibit  V-15,  D  is  plotted,  for  varying  levels  of  T  /T  , 
against  the  term  (Tg-Tc)/Tg.  As  used  here,  ( Tg-Tc/Tg )  is 
a  measure  of  the  percent  of  the  time  it  takes  to  complete  the  base¬ 
line  schedule  that  is  saved  by  implementing  the  schedule  with  con- 
currency . 

In  selecting  the  alternative  which  will  be  used  to  revise  the 
existing  schedule,  the  decision  maker  must  take  into  consideration 
the  other  scheduling  alternatives  which  can  be  used  in  conjunction 
with  concurrency. 

Some  of  the  alternatives  he  needs  to  consider  are: 

•  funding  of  parallel  activities,  in  order  to  increase  the 
probability  that  one  of  the  alternatives  will  successfully 
meet  the  goals  of  the  program ,- 
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Exhibit  V-15 . 
FUNCTION  OF 


THE  DEGREE  OF  CONCURRENCY  REALIZED  AS  A 
THE  PERCENT  OF  THE  BASELINE  TIME  SAVED 
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•  funding  repetition  of  activities,  when  a  critical  activity 
has  not  been  previously  successful; 

•  scheduling  activity  "slack  time,"  to  allow  for  the  un¬ 
foreseen  extension  of  the  duration  of  an  activity;  and 

•  lowering  performance  objectives  of  a  high-risk  activity 
and  compensating  by  increasing  the  performance  requirement 
for  a  lower  risk  activity. 

The  ultimate  set  of  decisions  made  by  the  PM/SHAPM  must  re¬ 
flect  the  particular  needs  of  the  project. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  following  are  MCR's  conclusions  and  recommendations 
concerning  our  research  on  concurrency. 


A.  CONCLUSIONS 

MCR's  research  on  concurrency  has  led  to  the  following 
conclusions : 

•  There  has  been  no  universally  accepted  definition  of 
concurrency ; 

•  Few  studies  have  been  conducted  which  specifically 
address  the  effects  of  concurrency  on  program  ac- 

.  qu is it ion; 

•  People  have  historically  perceived  concurrency  to  be 

a  contributor  to  serious  acquisition  deficiencies;  and 

•  Virtually  no  formal  direction  is  provided  to  the 
Program  Manager  concerning  techniques  for  develop¬ 
ing  or  evaluating  alternative  program  schedules. 

Several  major  conclusions  result  from  the  research  con¬ 
ducted  on  concurrency  to  date: 

•  To  be  effective,  concurrency  must  be  specifically 
planned  for  in  the  program. 

•  Due  to  the  nature  of  the  schedule  planning  process, 
however,  there  are  limits  to  the  horizon  for  con¬ 
currency  planning. 

•  Techniques  such  as  network  analysis  models  and  cost 
risk  analysis  models  are  useful  in  assessing  the  im¬ 
pacts  of  concurrency  and  are  already  available,  but 
have  not  been  coordinated  into  a  consistent  method- 
ology  useful  to  a  Project  Manager. 

•  In  order  to  evaluate  concurrency,  the  relationship 
between  program  events  and  activities  must  be  de¬ 
fined  and  specific  "checklists"  developed  so  that 
techniques  already  available  can  be  tailored  to 
specific  PM  needs. 

The  Project  Manager's  dilemma  is  that  he  must  (1)  determine 
the  magnitude  of  acceptable  risk,  and  (2)  apply  a  methodology 
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to  quantify  risk  in  order  to  effectively  make  cost/schedule/ 
risk  trade-offs. 

B.  RECOMMENDATIONS 

The  lack  of  an  acceptable  definition  of  concurrency,  one 
that  is  cast  in  operational  terms  and  can  be  used  as  a  basis  for 
developing  measures  of  effectiveness,  has  restricted  the  use  of 
concurrency  as  a  schedule  modification  technique.  In  order  to 
define  concurrency,  it  is  first  necessary  to  define  the  context 
in  which  the  concept  is  considered,  since  the  meaning  of  the 
unconscribed  term  is  so  general. 

For  the  purposes  of  this  analysis,  concurrency  must  be 
considered  as  an  acquisition  strategy.  It  reflects  a  deliber¬ 
ately  adopted  approach  for  constructing  and  modifying  a  project 
schedule  in  order  to  perform  trade-offs  or  prioritize  goals. 

Two  of  the  many  trade-offs  that  can  be  analyzed  in  this  context 
are : 

•  decreasing  resource  requirements  (time,  money,  manpower) 
at  the  expense  of  increasing  risk,  and 

•  decreasing  risk  by  increasing  one  or  more  of  the  resources 
attached  to  the  schedule  segment. 

In  defining  concurrency,  a  distinction  must  be  made  between: 
those  activities  or  events  which,  in  the  course  of  an  acquisition, 
are  scheduled  to  be  performed  at  the  same  time  because  it  is  a 
standard  procedure  for  ensuring  an  efficient  smooth-running  sche¬ 
dule;  and  those  activities  or  events  which  are  scheduled  to  be 
performed  at  the  same  time  as  a  mechanism  for  responding  to  a 
constraint.  Project  schedule  concurrency,  in  the  context  used 
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here,  relates  to  the  latter  category,  where  the  aim  of  the 
constraint  is  to  shorten  the  acquisition  time  for  the  product 
or  system  at  hand. 

With  these  thoughts  in  mind,  MCR  has  developed  the  following 
definition  of  concurrency. 

The  simultaneous  performance,  in  whole  or  part,  of  two  or 
more  normally  sequentially  related  activities  as  a  means 
of  optimally  utilizing  resources  or  managing  risk  in  response 
to  an  imposed  constraint  (schedule  compression)  or  to  fore¬ 
stall  a  scheduling  crisis  (schedule  protection). 

In  order  to  develop  an  operational  procedure  for  developing 

and  evaluating  project  schedules  that  incorporate  concurrency,  the 

following  steps  must  be  performed: 

•  complete  the  development  of  the  descriptive  model  to  a 
fourth  level  of  detail  in  order  to  accomplish  a  tailoring 
of  the  approach  to  a  weapon  system  level  of  detail; 

•  develop  weapon  system  specific  checklists  to  help  in  the 
cost  risk  and  schedule  risk  evaluation  of  project  sche¬ 
dules  ; 

•  test  the  methodology  using  actual  project  data  by  apply¬ 
ing  the  methodology  in  conjuction  with  an  on-going  acqui¬ 
sition  progam; 

•  explore  risk  analysis  techniques  appropriate  to  the  eval¬ 
uation  of  schedules  that  incorporate  concurrency;  and 

•  draft  a  reference  work  on  the  implementation  and  evalua¬ 
tion  of  concurrency  for  use  by  Project  Managers. 

The  goal  of  these  steps  is  to  provide  Project  Managers  a  use¬ 
ful  guide  and  methodology  for  implementing  the  notion  of  concurrency 
in  their  projects.  The  aim  of  the  approach  is  to  develop  an  imple- 
mentable  methodology  which  will  ultimately  help  shorten  the  acquisi¬ 
tion  time  for  major  weapon  systems. 
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